Function Syntax

Dmitry A. Soshnikov dmitry.soshnikov at
Thu May 12 14:51:47 PDT 2011

On 13.05.2011 1:25, Brendan Eich wrote:
> On May 12, 2011, at 1:06 PM, Brendan Eich wrote:
>> On May 12, 2011, at 10:55 AM, Brendan Eich wrote:
>>> Ruby is far from simple, btw. Check out
>>> and the wikipedia page it references.
>>> Looks like but not lambda can return from its caller.
>> From 
>> it 
>> should be clear I was missing the "block" target. Blocks are 
>> syntactically restricted to being downward funargs. Only if reified 
>> as Procs do they potentially escape to be called later when their 
>> lexical parent method could have already returned.
>> IOW, blocks are restricted to being downward-funargs by syntax at 
>> their expression site, and by default in the callee (without the & 
>> before the corresponding formal parameter).
> To say a bit more about this, here's a demo of the 
> downward-only-funarg nature of blocks passed as extra trailing 
> arguments, with no matching &parameters:
> def say
>     puts yield "world"
> end
> def say_hello
>     say {|x| "hello #{x}" }
> end
> say_hello
> The output is "hello world" of course, but Ruby's yield calls the 
> block without it escaping as a reified Proc that could be invoked 
> later, after the downward flow. Neat!
> (Rubyists, please correct anything wrong here.)

If the block is described explicitly in the method definition (that is, 
the last parameter with &) then it can be returned back as a result:

def foo &block

   if block_given?

     yield 10 # call the block implicitly 20 # the same, but explicitly

     block # return the block back



# pass the block downwards,
# and get it back (upwards) as a result

returned_block = foo { |i| print i }

# and call it again 30

Though, there's no much practical sense in this, since the block 
lexically is created in the global context of (in this case particular 
case) and captures its bindings, it, obviously isn't related with 
bindings of callee.

Brendan, take a look at this detailed source-article explanation of 
closures in Ruby 
(it's executable file, so a good tutorial). There all this stuff with 
blocks, etc is explained well.

P.S.: damn, it's so sorry that I haven't much time now to be involved 
deeply into the recent discussions of shorter function syntax. I hope 
I'll read carefully those threads later. A one thing I'd like to 
mention, we should not afraid of changes even if they syntactically 
aren't so familiar and habitual as were in Java.


-> syntax is / was long time before CoffeeScript. It's just a standard 
math definition of a function, it's used as a type of a "function" -- 
lambda abstraction -- in the lambda calculus, that is the "arrow type". 
It's used in many other langs, e.g. Erlang (which I use in my current 
job), Haskell, other. So, don't afraid it. Though, the issues with 
hand-written LL parsers should be also considered.


> I'm not suggesting we copy any of this, just passing along my 
> Ruby-n00b knowledge.
>> When we considered lambdas (the "Allen's lambda syntax proposal" 
>> thread from late 2008 to early 2009), we did not try to confine them 
>> syntactically to actual parameter lists. Did we miss a key 
>> restriction or feature of Ruby? I'm not sure, I'm too much a Ruby n00b.
> If blocks could not escape to be called after their enclosing function 
> had returned, then we would overcome the objection raised last time, 
> articulated best by Maciej:
> But Ruby went all the way, allowing a block to grow into a Proc and 
> outlive the method in which the block was expressed. I expect similar 
> "ecological pressures" to apply if we added blocks only as 
> downward-funargs.
> Plus, we'd still want shorter function syntax, not just blocks as 
> downward-only funargs (however nice for map, forEach, etc.).
> I will write up a block strawman, to give it a fair shake along side 
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list