On Mon, 24 Nov 2003, T. Onoma wrote:

> Take the def statement for example, why the odd sugar?: def
> blocky(x,y,&z).  why not def blocky(x,y){z}? But then & isn't exactly
> just sugar. Is it?

A Ruby message is in four parts:

 * receiver (optional, defaults to self)
 * selector (symbol of method name)
 * regular args (including optional "=" args, and *varargs)
 * block (optional, and not a real value)

The &z assigns to z the result of converting the block part of the active
message into a Proc object. This conversion happens because blocks are not
objects (apparently it's a significant speed gain to make it work that
way?)

> And I still get confused: when do I need the & in my method? And so
> on.

You need & (or equivalently, Proc.new) when you want to do something with
the block which is not possible by just using "yield" and "block_given?".
For example, to pass a block from a method call to another, you need to
pick up the block using & in the param-list (or Proc.new), and then pass
it to another method using & in the call.

> I've also wished that Proc/Lambdas had there own unique delimiteres
> and not shared them with hashes. (Couldn't hashes have shared
> delimiters with array instead? The => gives them away, after all.)\

Because of the need for a short and obvious way of distinguishing an empty
array from an empty hash. Apart from that it would have been nice. Another
idea is that if blocks were always like {|...| ... } with the vertical
bars, then no confusion is possible. Anyway, { ... } as a block is
equivalent to {|*| ... } IIRC (or maybe that's yet another thing that
changed to whatever else in 1.8.)

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju