On Sep 14, 2007, at 3:51 PM, Alan Kay wrote:

> Re: unification of blocks and methods (procedures).
>
> I first saw this in EULER (Wirth and Weber ca 1966), but then saw  
> an earlier similar notion by Landin in ISWIM and its predessors. I  
> used the idea in my first OOP language (FLEX ca 1967-9), which also  
> had complete static nesting of scopes, etc.
>
> But later I decided I didn't like blocks as values because they are  
> super time bombs when passed around and completely violate  
> encapsulation. I really wanted external objects (not internal  
> blocks) to be passed around, and wanted a simpler way to think of  
> contexts internally. So we left them out of the first few  
> Smalltalks. (I still don't like them ...)

On Sep 16, 2007, at 2:52 AM, Marcel Weiher responded:

> A block is just an unattached/anonymous method body and a method  
> just a block with a name that's attached to a class.   However,  
> with that unified view it becomes immediately obvious that there is  
> something wrong with blocks.  After all, we don't directly call  
> methods in other cases, that's early binding and a Bad Thing.   
> Instead we send messages to objects.  How does not naming the  
> method body make this type of early binding and leaking  
> implementation better?

That's not quite true. In Smalltalk, blocks *are* objects, and it's  
not possible to directly "call" a block. Instead, you send the  
message #value to it. This isn't early binding, because there are  
other things that respond to #value - MessageSends, for example, or  
Seaside's Continuations. Heck, Object provides a trivial  
implementation too.

I see what Alan was getting at about violating encapsulation: if you  
create a block that can access an object's internal state, then use  
it as a method of some *other* object, you end up with two objects  
that are quite intertwined, a sort of quantum entanglement between  
objects. I've done some neat stuff with that in Javascript, but I do  
agree that it dilutes the strict purity of object orientation that  
one finds in Smalltalk.

This is a bit strange, but I'm coming around to the idea that one of  
Smalltalk's greatest strengths is actually its block syntax. It'd be  
pretty tough to find a lighter-weight syntax for a closure. Even Lisp  
requires you to type out L-A-M-B-D-A, although the pain can be  
mitigated with macros. Ruby comes close, but {} doesn't actually  
create a real object. Javascript would be soooo much better if you  
didn't have to type out "function(){}" to create a closure. The  
lightness of Smalltalk blocks is what makes gems like  
#ifTrue:ifFalse: not only possible but practical.

Alan, can you elaborate on what you mean by "super time bombs?"

Colin