Re: [PATCH] lambda with normal block syntax

On Mon, May 26, 2008 at 10:48 AM, Yukihiro Matsumoto <[e-mail]>
wrote:

> Hi,
>
> In message "Re: [PATCH] lambda with normal block syntax"
>     on Mon, 26 May 2008 23:14:56 +0900, Dave Thomas <[e-mail]>
> writes:
>
> |You asked people to try the patched syntax that allows
> |
> |   meth {|a| a+1}, {|b| b*2}
> |
> |I think that this particular syntax is a lot less obtrusive, and a lot
> |easier to recognize, than
> |
> |   meth -> a { a + 1}, -> b { b * 2 }
> |
> |The first one is obviously a couple of blocks: that's what I read when
> |I see {|a| ...}.
> |
> |It seems that most of the posters on this thread agree. And, using
> |your criteria of "try it for a while and see", I'd judge that people
> |have tried -> for a while, and might well be happier with the {|| }
> |version.
>
> Personally I don't like
>
>   meth {|a| a+1}, {|b| b*2}
>
> which can be parsed
>
>   (meth() {|a| a+1}), ({|b| b*2})
>
> or
>
>   meth({|a| a+1}, {|b| b*2})
>
> or whatever.  I dislike this kind of ambiguity.  In fact, you would
> expect the latter, but I'm afraid Eric's patch gives you the former.


Yes, for compatibility the first interpretation must be used.

Keep in mind that this current syntax has the same issue:

meth {}, {}

except that the {} be a block or a Hash.

This is one of the reasons I most use () around my arguments.

This could be a very evidence of (bad) ambiguity.  That's why I asked
> people to try the patch.
>
> Perhaps it works better with Groovy's semantics of block passing (last
> explicit argument with slightly different call syntax).  But not with
> Ruby's implicit argument style, which I am not going to change.
>
> |I'd also argue that the {|a| } makes for a better language. My
> |experience teaching this stuff shows that people are confused by the
> |large number of different options that surround blocks. Unifying block
> |parameters with method parameters, and then removing the need for this
> |somewhat strange -> notation, will reduce the number of special cases,
> |and make it a lot easier for people to understand the language. And
> |that's a major cognition win.
>
> This notation introduces something new (a block without any attached
> method, or lambda), with syntax almost indistinguishable from existing
> one (a block attached to a method).  I hesitate to give too similar
> syntax to something different.  The point should be how different (in
> recognition) a block without attached method (lambda) and an usual
> block in Ruby.  I see them different (at least in Ruby).  Others may
> not.


Another symbol that has a similar ambiguity that everybody deals with just
fine is "-" (minus).  Depending on the context, it can have two different
meanings:

A-B : binary "-", A - B
-A : unary "-", negative A, equivalent to: 0-A

Similarly, with {|| }, it can have two different meanings depending on the
context:

meth { |args| code } : binary "{", call meth with a block
{ |args| code } : unary "{", lambda, equivalent to: lambda { |args| code }

From this perspective, 0 is to - as lambda is to { || }

I think the biggest problem is that the unary block case (the implicit
lambda) also has additional ambiguity with Hash.  It is unfortunate that |'s
are required in this case (to differentiate with Hash) and the normal block
(binary "{" operator) doesn't require them.  But, I think this trade-off is
better than creating something completely new (i.e. the -> syntax).

|Please, please consider adding both these patches into 1.9.
>
> * block parameter with default argument patch: likely.
> * block without attached method patch: need more persuasion.


Great!  This is the priority I'd like to see them.  If default argument
patch is applied, the various lambda shortcuts ("->", the bare block syntax,
and all other suggestions) aren't necessary and would only be syntactic
sugar.  Personally, I'd rather have the bare block lambda syntax (it matches
the normal blocks we have now) or have no lambda shortcut syntax.

Eric