On Sun, Aug 23, 2009 at 2:00 PM, Caleb Clausen <caleb / inforadical.net>wrote:

> 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...


Both of those cases continue to parse as a Hash with this patch.
Effectively, the patch simply fills in SyntaxError cases of { ... }, which
should mean that anything that parsed as a Hash before will continue to do
so, but anything that couldn't parse before will become a proc.


> 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?


Understood -- but you do have the implementation to refer to. I agree that
in order for this to be accepted, we would need to provide new RubySpecs to
specify the behavior. I believe ujihisa is working on that.

-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325