Hi,

Colin Putney wrote:
> 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.

Alan means, correct me if I'm mistaken, that the notion of code blocks, 
Lambda like closures wasn't present. What alternatives were discovered? 
Then and since?

I suspect that what is not meant by Alan's comment, again correct this 
for accuracy, is the notion of a unified Smalltalk Block and Method 
Syntax as was suggested.


>>
>> 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 ...)

Alan, that must have been an interesting debate within the group. By 
external objects would they perchance have any difference from Object?

In a way you almost want an interaction using a entirely different 
contextual mechanism that pulses a constraint network depending on the 
objects and methods involved. A non-messaging contextual paradigm, of 
course expressed in unary, binary and keword message passing syntax 
[UBKMPS].


>
> 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?

Hmmm... Early Binding = Bad Thinking a Thing.

In a way you want a simulation of some sorts that performs Late Binding 
in the method contexts dynamically on the fly for a deterministic 
outcome each time it's run. Non-linear indeed.


>
> 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.

A difference in view point enables dual understanding of all known 
perspectives.


>
> 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.

A isue with blocks is that they are imperative. How about using the 
Declaratives written in [UBKMPS] form instead of the imperative words 
that normally show in a Block's square brackets?

The Knights of the Square Brackets can figure this one out quickly. The 
peasants picking from the aromatic plants might catch up eventually with 
our help.


>
> 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. 

Yes, Block Syntax, "[ ]",  is as important as the notions of messaging 
and objects in it's own right. Unified Method and Block Syntax orders of 
magnitude more so.

Imagine Blocks can be evaluated ANY WAY that YOU THE PROGRAMMER+USER 
decide at runtime deferred to realization in your specific use case 
scenarios. Block evaluators, a few of which were recently present in an 
prior thread last week are normal things that you can extend Smalltalk 
or ZokuScript with just by writing using unary, binary and keyword 
message passing syntax that we know so well. Think about it. Write some 
examples. Visualize how this would change your coding of programs and 
the programs themselves could be so much more less brittle. 
Pragmatically how to implement these visualizations in realistic ways? 
What critiques are there from the perspectives of existing implementations?

This achieves what at least one language designer aims for: a opening 
for a whole new dimension for extensions by everyone with ease {and 
their great ideas} over time as the extensions unfold in unpredictable 
ways in the years to come. Who imagined that Block>>#values would come 
to the forefront as a new dimension? New dimensions of openings for 
extensions in the library using standard unary, binary and keyword 
message passing syntax are where the future comes from. From this 
authors perspective, that is, and maybe yours.



> 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.

ifNil:ifNotNil:



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

Aspects of existing blocks that blow applications out of the water or at 
least do so through increasing complexity via a magnification effect 
often disproportionate to ones ability to comprehend the full operations 
of the program as it crashed or produced it's operative results in the 
real world.

Something like that maybe?

In summary, using Unary, Binary and Keyword Message Passing Syntax 
[UBKMPS] is an essential way to make the evaluators of Blocks unlimited.

All meta operations in UBKMPS make this possible using what you already 
know.

All the best,

Peter William Lount
peter at smalltalk.org


ps. Each node in the Tile 64 Processor can see the same network traffic 
at roughly the same instant assuming network multi-casting. What 
applications for this can you think of? Parallel operations play into 
this inquiry.