#perform: - the ultimate lambda?

[Avi Bryant <address@hidden>]

On Fri, 24 May 2002, Dan Moniz wrote:

> SICP has a similar point, in that you construct an object system out of
> closures. I look at closures being more generic than objects, whereas
> objects have very specific properties. I suppose it depends on what I'm
> doing and what I'm doing it with at the time that would determine whether
> or not I found my objects as lame closures or closures as lame objects. I
> tend to feel that, between the two, I would rather have real closures, and
> if necessary, I'll build my own object system thank-you-very-much over
> having to be constrained in an "objects only" universe. But then, I still
> liking hacking in Smalltalk for fun sometimes.

Alan Kay makes an interesting proposal in a paper on the history of
Smalltalk (sorry, don't have the reference handy).  He says something like
"pick the most sophisticated concept you want the language to have, and
build everything else out of that".  Hence, in Smalltalk, closures are
objects, not the other way around.

It's a nice theory, and Smalltalk bears it out well, although since
blocks do have special VM support, I'd be more comfortable saying that
Smalltalk takes both objects and closures as given, and builds everything
else from there - which it does, very elegantly, right down to the if
statement.

The upshot is that Smalltalk is amazingly malleable - as I like to point
out, adding call/cc to Squeak was on the order of 10 lines of Smalltalk
code.  This is because even very low-level constructs like stack frames
are implemented in terms of high level objects.  I find it interesting
that something like Scheme, which starts with a few simple special forms
and works upwards, doesn't end up with the quite the same flexibility.

Avi