Yehuda Katz wrote:
> On Sat, Aug 22, 2009 at 7:38 PM, Caleb Clausen <caleb / inforadical.net 
>     How do you disambiguate this case:
> 
>      { foo bar => baz }
> 
>     which could be parsed 2 ways:
>      { foo(bar) => baz } #a hash
>     or
>      { foo(bar=>baz) }   #a block
> 
> 
> Things that currently don't parse are fine to become blocks. I'd be 
> 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?

There's these 2, which parse as hashes currently:

   { p () => () }
   { p {} => {} }

Which confuse me, and presumably other humans. Maybe not confusing to 
parsers...

If you want to just define my first example to be a proc, that's fine. 
(I think it will be easy enough to implement that way....)

But I'd like to see a more explicit description of how this would work, 
if I am to implement it. Making reference to an existing parser 
implementation is unhelpful for me, especially as I am not familiar with 
the internals of that implementation. Things that cause parse errors for 
MRI may not for redparse; redparse is generally looser and more tolerant 
than MRI parse.y. In other words, what would the appropriate section of 
a ruby standard read when describing this feature?