Hi --

On Mon, 21 Mar 2005, Florian Frank wrote:

> David A. Black wrote:
>
>> For example, {|| } (lambda without lambda).  For me, the question is
>> not whether it's possible to understand it (which it is).  Rather,
>> the question is: if Ruby had been designed from the ground up with a
>> literal function constructor, would it have been {|| } ?  If so, then
>> fine.  If not, then {|| } would be an add-on that is not properly
>> integrated into the language.
>
> I think "f = {|| }" is analogous to "def f() end", and I really like it. (To 
> say the truth, this syntax for lambda is part of the language of my dreams. 
> ;) It would be even nicer, if the shortcut "f = {}" would be possible as 
> well, but the empty Hash constructor collides with that syntax. Like others 
> have said before, I'd rather substitute the hash constructor (but only in 
> Ruby 2.0) with another syntax to get the "{}". It's associated in C-languages 
> with "code to be executed" anyway, so it would meet newbie's expectations AND 
> it would make Ruby more self-consistent.

I don't think making Ruby resemble other languages makes it
*self*-consistent, but rather more consistent with languages other
than itself.  I'm also not a big believer in meeting nubies'
expectations.  Especially for Ruby 2.0... it's definitely past the
point of needing to "make <other language> programmers feel at home."
They will, if they like Ruby, and meanwhile it's important for Ruby
programmers to feel at home :-)

> BTW: Is a syntax planned to define default values for blocks? It would be 
> good to be able to define a method
> def f(x = 1) 2 * x end
> with a block like
> define_method(:f) { |x=1| 2 * x }
> I think blocks and methods should be as similar as possible, and this would 
> help a lot. (Or what about keyword arguments for Ruby 2.0?)

There's a strong case to be made for unification of blocks, lambdas,
Procs, and methods.  I'm not sure where Matz stands on that at the
moment.


David

-- 
David A. Black
dblack / wobblini.net