From: Florian Frank Date: 2005-03-21T19:18:07+09:00 Subject: Re: Paul Graham recommends Ruby 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. 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?) The implementation of call without "call" is another thing: it seems to be rather hackish at the moment. Expressions like f()() for f = {|| {|| 1} } aren't possible, while f()[] is. Perhaps it would be better, to leave this unchanged, and rely only on the #[] method instead. It would be easier to explain, that f() is a call to the bound method f of self, while f[] is a call to the #[] method of object f, which could be a Proc. f could be bound to an object/class with define_method(:f, &f) and then called from this object's context as f or f(). Ah, and now it's possible to have SyntaxErrors in 1.9, if you first ask for them: a = :outer f = {|;a| a = :inner } # local variable name conflict Is this useful? I don't see, in which case it would be. -- Florian Frank