From: Eric Mahurin <eric_mahurin@...>
Date: 2005-08-07T22:42:28+09:00
Subject: Re: new block notation

--- Jim Freeze <jimfreeze@gmail.com> wrote:

> > block and in the method/lambda/block definition the "&"
> > converts a block to a lambda.  Well, how about making the
> unary
> > "&" in front of a block converting it to a lambda?
> > 
> > f = &{...}  # equivalent to f = lambda{...}
> > 
> > This is not really a unary "&" operator but rather a &{...}
> > construct, but it does flow with the current unary "&"
> syntax,
> > kind of.
> 
> > def test(lam=nil,&block)
> >     ...
> > end
> > 
> > test ->(..){..}
> 
> This looks similar to what exists now in 1.8.2.
> 
>   block = lambda { ... }
>   test(&block)  #=> lam =nil
>   test(block)   #=> lam = block

Yep, but what I'm proposing here is illegal in 1.8.2 so it
won't break compatibility and not ambiguous like the current
1.9 syntax.

f = lambda { ... } # 1.8.2
f = &{ ... }       # proposed
f = { ... }        # old 1.9, can be ambiguous with hash
f = ->(..){ ... }  # new 1.9

test &f            # no change, lam=nil, block=f
test f             # no change, lam=f, block=nil
test { f[] }       # no change, lam=nil, block=lambda{f[]}
test lambda{ f[] } # proposed, lam=lambda{f[]}, block=nil
test &{ f[] }      # proposed, lam=lambda{f[]}, block=nil
test ->{ f[] }     # new 1.9, looks ambiguous

"test &{ f[] }" comes close to causing a problem because it is 
legal syntax in 1.8.2, but semantically is illegal because you
can't convert a hash to a block.  The parser would need a
branch when it encounters an arg that starts with a "&" - if
the next token is a { it is treated as block to lambda
conversion, otherwise it is treated as lambda to block
conversion.  Just a trivial one token lookahead.

Just allow & instead of lambda to convert block to lambda since
& already serves lambda<->block conversion.




		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs