--- Yukihiro Matsumoto <matz / ruby-lang.org> wrote: > Hi, > > In message "Re: new block notation (was: Re: ruby-dev summary > 26468-26661)" > on Fri, 5 Aug 2005 03:23:40 +0900, Brian Wisti > <brian.wisti / gmail.com> writes: > > |Aww, but now it looks even less like Smalltalk! I kid, I > will live > |just fine with either notation style, although I prefer the > current > |style. I'll keep on using the current style for as long as > it is > |available, for one simple reason: less punctuation. > > That's OK. The new notation is to replace lambda. > > matz. I noticed this experimental behavior disappeared: f = { ... code .. } So this new syntax tries to address 2 issues: 1. Allowing args to have defaults in a block. 2. Making a lambda without the "lamda", "proc", or "Proc.new" ... and also not cause ambiguities with a Hash. So before, the experiment was this (no default args and ambiguities with Hash): f = { |a| ... } and now you are thinking about this: f = ->(a) { ... } To me, this suffers readability because there are too many symbols in a row: =->( Wasn't this kind of thing the primary problem with perl - too many punctuation characters made it difficult to read. It seems like you are between a rock and a hard place (preserving backwards compatibility) to solve this problem. I don't see one great solution. The best I can come up with is to use syntax like we have now except a) use symbols other than | that allow no ambiguity in the expressions (I think :+space would work), and b) force an argument list to not cause ambiguities. So you'd have this: f = { : a,b=1|2 : ... } f = { : * : ... } # equivalent to f = lambda { ... } Still kind of ugly though. Too bad you have to leave hashes as first-class. If you made them second class instead ( hash(key=>value,...) or Hash.new(key=>value,...)), that would allow more freedom. I think code blocks are much more important than hashes. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs