On Sun, Aug 23, 2009 at 3:33 PM, Yukihiro Matsumoto <matz / ruby-lang.org>wrote:

> Hi,
>
> In message "Re: [ruby-core:25049] Re: Proposal: Simpler block format"
>     on Sun, 23 Aug 2009 15:53:03 +0900, Yehuda Katz <wycats / gmail.com>
> writes:
>
> |Things that currently don't parse are fine to become blocks. I'd be
> worried
> |about a case that currently parsed fine as a Hash but might be expected to
> |be parsed as a block if this feature existed. Can you think of any?
>
> I don't worry about the ambiguity for the parser, but have anxiety for
> humans.  Under the new syntax, when we see
>
>  m {"this is a block not a proc"}
>
> there are two possibility.  And it would be burden for mind of the
> programmers.  That's the reason I insisted the past proposal (that
> was from David Black, IIRC).  This time, we have working code for the
> proposal, so we can try.  Let's see how we feel.


The compelling this for me is that it makes methods that take multiple
blocks easier for programmer to read. For programmer, one big confusion in
Ruby is difference between proc, block, lambda and method. Unifying syntax
for block and proc shows that they are really just same thing, with proc
passed as parameter and block passed as special parameter.

Then whenever programmer sees { something } they know it is "proc" with
lexical scope, and whenever programmer sees ->{ something } they know it is
"lambda" with function scope.

I would even be in favor of def { } as lambda syntax, which would make clear
to programmer that this block behaves just like normal method. Then we have
just two things: def for method-scope (def something() end and def { }) and
bare { } for block scope.


>
>
>                                                        matz.
>
>
>


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325