Re: [PATCH] lambda with normal block syntax

On Thu, May 29, 2008 at 8:41 AM, Yukihiro Matsumoto <[e-mail]> wrote:
> Hi,
>
> In message "Re: [PATCH] lambda with normal block syntax"
>    on Wed, 28 May 2008 21:46:06 +0900, "Eric Mahurin" <[e-mail]> writes:
>
> |Sounds reasonable.  Just curious though, what part of the
> |ambiguity/precedence do you think isn't acceptable?  a) {||...} as a
> |block vs. {||...} as a lambda, b) {...} as a hash vs. {||...} as a
> |lambda, c) both, d) that we'd have both ambiguities, or e) something
> |else?  Personally, I think the biggest downside is between a {...}
> |hash and {||...} lambda.  The block vs. lambda seems reasonable
> |because it is analogous to something like binary vs. unary "-".
>
> The case I hate most is
>
>  meth {|a|...}
>
> can be parsed (by humans) both
>
>  meth({|a|...})
>
> and
>
>  meth() {|a|...}
>
> having too confusing semantics.

But, this ambiguity already exists today:

meth {}

can be parsed (by humans) both

meth({}) # {} is a Hash

and

meth() {} # {} is a block

Precedence resolves this: block has higher precedence.

> If Ruby works like Groovy, above two
> would be same behavior, but it is not, and not going to be changed.

Agreed.

> Of course we can disambiguate them by explicitly add parentheses, but
> still I don't like this confusion enough to give up this syntax.

I have to admit that I use parens most of the time with arguments,
because the precedence gets confusing and I need them to get what I
want many times.

Eric