On Sat, Aug 22, 2009 at 7:38 PM, Caleb Clausen <caleb / inforadical.net>wrote:

> Yehuda Katz wrote:
>
>> I'd like to propose that we add the following syntax for procs in Ruby:
>>
>>  x = { contents }
>>  x = { |y| contents }
>>    { contents }.should raise_error(Exception)
>>    call_method({ proc_1 }, { proc_2 }, { proc_3 })
>>  Essentially, any use of {} that was not a Hash would become a proc.
>> Effectively, this includes all use of {} that produces a SyntaxError at the
>> moment ({} remains the equivalent of Hash.new). I suggested this to
>>
>
> 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?


>
>
> (Note, however, that the first snippet is currently a syntax error....)
>
> I think Rick DeNatale raises a good point too.
>
> Ruby 1.9 used to have a feature like this, but it was taken out, I think
> out of fear of the ambiguities it creates. As a user, I like this feature a
> lot. But as an implementor of ruby's syntax, I've learned to dread
> ambiguities; they just make my life hard. That's not necessarily a reason
> not to do it, but I would like the ambiguities to be very carefully
> considered and explicitly mapped out.
>
>


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