The state of the Lambda in Ruby 1.9

Ruby's Blocks are one of the crucial features that allow to write concise and highly reusable algorithms. If nothing else, it helped to extinguish the venerable for loop. The concept has many names in other languages and theory:

lambda function

anonymous function

closure (e.g. the term used for the lamdba functions in Java 7) This is a somewhat confusing term, because the term closure also refers to the capturing of the scope surrounding the code. A Block doesn't necessarily need to capture the scope - this code

x = lambda {|x,y| x + y}

doesn't use any free variables (i.e. variables that are unbound; x and y are declared in formal argument list), and hence doesn't require the creation of a closure

Blocks come in many shapes and forms in other languages, with a varying amount of verbosity. One of Ruby's influences, LISP, for instance uses this syntax:(lambda (arg) "hello world").Another language influential in Ruby's design, Smalltalk, uses a very concise syntax using brackets:[arg| ^"hello world"].

Ruby's most convenient and often used syntax for Blocks is as a parameter to a function, which allows to simply append a Block surrounded by either do/end or braces {/}. Eg.

5.times {|x| puts x}

It's convenient, and also allows idioms such as Builder, which allows to create hierarchical data structures very easily by using a nested Blocks. (Tip: An upcoming article here on InfoQ will explain the details of creating a Builder in Ruby - watch out for it in the 2nd half of January).

However, there was one problem: passing more than one Block to a function or method didn't work as easily. It was possible, but not with this shorthand. Instead, a Block had to be created using either the Proc.new {} or lambda {} notations. While not horrible, these options are much more verbose and introduce unwelcome tokens that clutter up the code. (Note: Proc.new {} and lambda {} notations have subtle differences as well, but this is not significant in this context).

Workarounds are possible for this in certain situations. For instance, if an API call requires multiple Blocks, helper functions could be mixed into the class to a) help with Blocks and b) have the side effect of looking like named arguments:

find (predicate {|x,y| x < y}, predicate{|x,y| x > 20})

The predicate function is nothing more than:

def predicate(&b) b end

I.e. returns the Block. Whether this is appropiate or not depends on the specific use case. In this case, the shown code is - arguably - more expressive then the equivalent:

find (lambda{|x,y| x < y}, lambda {|x,y| x > 20})

Why? Because lambda leaks implementation details about how this is implemented - with one block argument, no extra keyword would be needed. The predicate solution annotates the code and generates the lambda. To be clear: this is a workaround.

Ruby 1.9 now introduces an new, more concise syntax for creating lambda functions:

x = ->{puts "Hello Lambda"}

The new syntax is shorter and removes the unfamiliar term lambda. To be clear: this is syntactic sugar. It does, however, help to write APIs that yield very readable code. Some of these APIs might be called "internal DSLs", although the definition for those are quite fuzzy. For these, the new lambda definition helps getting rid of the quite obscure term "lambda" in the middle of otherwise purely domain or problem specific code.

Explicitly invoking one block from another in Ruby 1.9.0. This method was something I didn't even cover in my previous post, because the parser would simply blow up when parsing |*args, &block|. Here's what it looks like. [..]

In 1.8, the code would print "I'm not local to this block", wheras in 1.9 it prints "Outer Scope". In short, blocks now behave as expected: the block argument shadows the variable of the same name in the outher scope inside the block. (Let's preempt the question "How can I access the variable in the outer scope?". You don't - just choose a different name for the block argument).

What do you think about the Ruby 1.9 lambda/block changes? Do they address all existing concerns or are there other problems left?

I thought the lambda word was clear, and makes perfect sense what you are doing. I guess its just taste. the shadowing is nice, and will either break a lot of existing code (which was bad to start with) and/or get rid of a confusing class of bugs.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.