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
http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby
and the wikipedia page it references.
Looks like Proc.new but not lambda can return from its caller.
From
http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Method_Calls 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 ¶meters:
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
block.call 20 # the same, but explicitly
block # return the block back
end
end
# pass the block downwards,
# and get it back (upwards) as a result
returned_block = foo { |i| print i }
# and call it again
returned_block.call 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 http://innig.net/software/ruby/closures-in-ruby.rb
(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.
P.S.[2]:
-> 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.
Dmitry.
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:
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008390.html
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
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
