David A. Black wrote:
> I'm trying to figure out why I don't like this (including the {||...}
> form.
> 
> I think it's because it requires visual backtracking.  When I see:
> 
>   x = {
> 
> I read it as a hash constructor.  With the lambda possibility, I have
> to read further, and *then* understand what the { meant.

I'm not sure if it's the "visual backtracking" aspect, but I agree, I 
have trouble with braces.

It's even more confusing that you can also define a block with 'do ... 
end', and that you can create anonymous methods with either "proc", 
"Proc.new", "lambda" and the new syntax.

If it were up to me, I'd make it so braces can *only* be used for 
defining hashes, and then make all the methods of defining a Proc object 
do exactly the same thing:

(do puts "Proc!" end) == lambda do puts "Proc!" end == proc do puts 
"Proc!" end == Proc.new do puts "Proc!" end

It may be a really unpopular thing to get rid of braces for Procs, but I 
still think it would be a good idea.

1. Confusion between hashes and blocks, especially blocks without 
parameters.
2. Inconsistency: all "blocks of ruby code" are terminated by 'end' 
except for some blocks, which are terminated by '}'
3. No clear choice: 'do ... end' blocks are exactly equivalent to '{ ... 
}' blocks.  Because of that, people have their own rules about what they 
use and when they use it, and that makes for confusion when reading 
someone else's code.

I know this is far too radical a change for the current Ruby line, but 
maybe for Ruby 2.0 Matz could consider this kind of change?  (Unless I'm 
soundly booed for even suggesting it).

Oh yeah, and while I'm fundamentally changing the language, howsabout:

x = lambda
       puts "Proc!"
     end

or
x = proc puts "Proc!" end

(note the conspicuous lack of "do")

Ben

P.S. Flame away!