On Sat, Aug 22, 2009 at 7:38 PM, Caleb C= lausen <caleb= @inforadical.net> wrote:

Yehuda Katz wrote:

I'd like to propose that we add the following syntax for procs in Ruby:=

=A0x =3D { contents }
=A0x =3D { |y| contents }
=A0 =A0{ contents }.should raise_error(Exception)
=A0 =A0call_method({ proc_1 }, { proc_2 }, { proc_3 })
=A0Essentially, any use of {} that was not a Hash would become a proc. Eff= ectively, this includes all use of {} that produces a SyntaxError at the mo= ment ({} remains the equivalent of Hash.new). I suggested this to

How do you disambiguate this case:

=A0{ foo bar =3D> baz }

which could be parsed 2 ways:
=A0{ foo(bar) =3D> baz } #a hash
or
=A0{ foo(bar=3D>baz) } =A0 #a block

Thi= ngs that currently don't parse are fine to become blocks. I'd be wo= rried about a case that currently parsed fine as a Hash but might be expect= ed to be parsed as a block if this feature existed. Can you think of any?

=A0

(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 ou= t of fear of the ambiguities it creates. As a user, I like this feature a l= ot. But as an implementor of ruby's syntax, I've learned to dread a= mbiguities; they just make my life hard. That's not necessarily a reaso= n not to do it, but I would like the ambiguities to be very carefully consi= dered and explicitly mapped out.

--
Yehuda Katz
Develope= r | Engine Yard
(ph) 718.877.1325
--000feaefb8c45fbd770471c98d08--