Re: [PATCH] lambda with normal block syntax

Hi,

Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: [PATCH] lambda with normal block syntax"
>     on Mon, 26 May 2008 14:47:58 +0900, "Eric Mahurin" <[e-mail]> writes:
> 
> |What was the reason for the -> lambda introduced in r8847 over the do/end or
> |{||} lambda from r8044?
> 
> The users complained that was too easily confused with hashes.

Perhaps this confusion could be dispelled by a simple rule:  if you
begin a literal hash's content with |...|, then you are creating a
literal block.  Otherwise, you are creating a literal hash.

> In addition,
> 
>   foo {|a|...}
> 
> can be parsed both
> 
>   foo({|a|...})
>
> and
>
>   foo(){|a|...}
>
> that could cause more confusion.

I believe that there is no confusion among the three cases you
presented because IMHO they represent two different semantics.

For instance, as the second case illustrates, parentheses allow the
user to pass literal blocks as regular method parameters (not as the
singular implicit block parameter).

For example, I find that this:

  foo( {|a|...} )

is clearly equivalent to this:

  x = {|a|...}
  foo(x)

and also equivalent to this:

  x = {|a|...}
  foo x

In contrast, I find that these:

  foo {|a|...}
  foo() {|a|...}

are clearly specifying an implicit block parameter to the foo()
method because otherwise--if they were indeed specifying an explicit
*method* parameter, then--it would conflict with Ruby convention:

  x = {|a|...}
  foo x        # convention says that x is a *method* parameter!
  foo(x)       # convention says that x is a *method* parameter!
  foo() x      # convention says that this is a syntax error!

> |Was it default arguments?  If so, could my first
> |patch be used for default arguments (use primary instead of expr for default
> |vaule to resolve | ambiguity) instead?
> 
> It is interesting idea.  Let me see.  Wait for a while.

Thank you very much for considering these ideas!
I eagerly (and patiently) await your conclusions.  :-)

Cheers.