the first reason is to respect the history of Lisp
How strange then to talk of blocks (like this Smalltalk) rather than lambda

dictionary keysDo: [:key| 
   *do something with key* 
   ]

dictionary keysAndValuesDo: [:key :value| 
   *do something with key and value* 
   ]

In an OO language like Smalltalk, all the 'named functions' are object methods - they are message sends to some object. In contrast, Smalltalk blocks are standalone functions.

> > Another nice feature of anonymous closures is that I
> > have more control over the order of operations
>
> Seems like this is the same with named or anonymous
> functions (in Nice http://nice.sourceforge.net/index.html

Right, but the point I was trying to make was that by supporting closures as expressions you can say "after this, do that" instead of "after this, do that thing which I defined somewhere else". But it looks like Nice supports both.

Nice is nice. =)

Are there new uses that didn't exist in Smalltalk?

Here are some Smalltalk equivalents:

> - to pass a 'discriminating' function, like in
> Enumerable.sort()
>
> array_of_persons.sort { |p1,p2|
> p1.name <=> p2.name
> }

Smalltalk has a special SortedCollection, so we might say
array_of_persons asSortedCollection: [:p1 :p2| p1 name < p2 name ]

or for an in-place sort on the array
SequenceableCollectionSorter sort: array_of_persons using: [:p1 :p2| p1 name < p2 name ]

> or, even better, in sort_by() (that internally does a
> a shwartzian transform)
> array_of_persons.sort_by {|p| p.name}

'shwartzian transform' this caching optimization isn't built-in to Smalltalk.

> - for threads:
> Thread.new { do stuff}

t := [ do stuff ] fork.

or more interestingly

p := [ do stuff ] promise.

> - for event/signals/callbacks:
> at_exit { puts "existing now.."}
> or
> button.onclick { puts "clicked"}

Object when: anEventNameSymbol do: aBlock

(More often in the Event System a specific method symbol is used rather than aBlock.)

In Smalltalk even conditionals and loop statements are defined with blocks:

i<5 ifTrue: [ do something ].
[ i<5 ] whileTrue: [ do something ].

Phil, I knew that there is another way in Ruby to handle closures. I think the argument you mention is called a 'proc' object. My point was that the construction with 'yield' is bad design.
You will notice that Matsumoto takes the 'yield' approach as the way to explain it. I think it is somewhat the dominant approach in Ruby. So you will not be able to conclude on the basis of the interface that the method does not take a block or closure since there is a construction, that is often used that doesn't show up until you read the code.
I think it is a redundant construction that wastes a whole language keyword while the other construction is also more object-oriented. It does not follow Matsumatos principle of least surprise.
If you're from the planet Perl you'll think that's a feature of course. :-)

Concerning the documentation: the documentation of the standard lib has been set up 2003-11-23 so that wasn't there when I worked with Ruby in June and July. I remember that I ran rdoc over the stdlib and just found empty html. Looking at the dates in code comments I see that a lot of them have been added around november and december this year. Apparently people had the same opinion that it won't do without uptodate API docs.

I was very disappointed when I found the empty rdoc html, so this is a great improvement. Thanks for mentioning it. I had't noticed.

My 'hobby language' comment was a bit provocative I admit. My point is just that I can not deliver code to a customer on a platform that has no uptodate documentation. Especially since Ruby is an obscure language. With 'obscure' I mean that not a lot of developers are proficient in it. In the Netherlands at least. I'd be throwing a heap of unmaintainable code on customer.
So in that way I think that a language implementation that does not document it's standard libs and keep this uptodate is not fit for professional, commercial work. If you're just writing code for yourself it's no problem of course. (If you want to invest the time)

Anyhow,
Groeten,
Joost