On Sun, Aug 23, 2009 at 3:33 PM, Yukihir= o Matsumoto <mat= z@ruby-lang.org> wrote:

Hi,

In message "Re: [ruby-core:25049] Re: Proposal: Simpler block format&q= uot;

=A0 =A0on Sun, 23 Aug 2009 15:53:03 +0900, Yehuda Katz &= lt;wycats@gmail.com> writes:

|Things that currently don't parse are fine to become blocks. I'd b= e 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 anxiet= y for
humans. =A0Under the new syntax, when we see

=A0m {"this is a block not a proc"}

there are two possibility. =A0And it would be burden for mind of the<= br> programmers. =A0That's the reason I insisted the past proposal (that was from David Black, IIRC). =A0This time, we have working code for the
proposal, so we can try. =A0Let's see how we feel.

The compelling this for me is that it makes methods that take m= ultiple blocks easier for programmer to read. For programmer, one big confu= sion 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 i= t 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, w= hich would make clear to programmer that this block behaves just like norma= l method. Then we have just two things: def for method-scope (def something= () end and def { }) and bare { } for block scope.

=A0

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0matz.

--
Yehuda Katz
Develope= r | Engine Yard
(ph) 718.877.1325
--00c09f97253f2a6f2e0471d70b5b--