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

Cheers,

Alan

At 03:11 PM 9/14/2007, Peter William Lount wrote:
>Hi,
>
>Martin Beck wrote:
>>Am Freitag, 14. September 2007 21:44:48 schrieb Peter William Lount:
>>
>>Hi Peter,
>>
>>
>>>>However, you indeed change the syntax of blocks for merging block syntax
>>>>with method syntax when you say
>>>>
>>>>[firstName: aString | firstName := aString ].
>>>>
>>>>aren't you?
>>>>
>>>Yes, the syntax adjusts towards a unification of Blocks and Methods.
>>>
>>Ok, but in my opinion, it is not necessary to adjust the syntax to 
>>achieve this unification. I'd rather interprete a Method as a named Block.
>
>With the change that I suggest it can use either format. It's the 
>most general approach.
>
>>Your syntax change does early binding of a name to an implementing 
>>Block, which we don't want in Smalltalk... :)
>
>Please explain further, I didn't get your meaning.
>
>>The current block syntax does - as you stated, too - already 
>>incorporate the features needed in a method, like temps and 
>>arguments. So all you need, is to bind a Block to a class und a 
>>special method name (which has to have the same arg count).
>>
>
>Yes, and resolve any "variable names" that need to be tied down to a 
>scoping context. Either at the point the block is attached to a 
>class (or traits node) or at the point when a block is evaluated as a block.
>
>
>>While running the VM/compiled code, the context decides, whether 
>>the block is evaluated in a normal way, e.g. a home context and 
>>correctly interpreting the return etc., or whether it is evaluated 
>>in a method context. So we are at your differant evaluators again. ;)
>>
>
>Well I'm not sure that we'd need a new evaluator for that, but 
>that's an interesting idea. Let me think on that some more.
>
>>
>>>>I personally like to see a Block as a simple collection of statements.
>>>>
>>>Yes, that's a very powerful perspective. It's a hierarchical collection
>>>of statements in the more general form.
>>>
>>A hierarchical collection which could be called Abstract Syntax Tree, hehe.
>>
>
>;-) Yes.
>
>>Not to convince you (which is not needed ;) ), but just to add my 2 
>>cents: We all know, that in a standard Smalltalk VM a Block is 
>>simple compiled code, which can [be] evaluated resulting in a 
>>single value. However, if you try to explain such lambdas, closures 
>>(or any other name you might think of) to Smalltalk newbies, 
>>especially those from C/C++/Java backgrounds, you end up in saying 
>>to them: "A Block is source code you can save in a variable and 
>>execute it later". I don't want to discuss, whether that is right 
>>or wrong, but I think it helps them to understand a little bit of 
>>what is really meant.
>
>I find that it's a very effective approach of explaining it to 
>people. At least it's a great place to get start explaining 
>Smalltalk blocks to them.
>
>
>>That differs from the former statement, that it says "source code". 
>>And source code is a (hierarchical) collection of statements, even 
>>in Smalltalk - at least to some extent.
>>
>
>Yes.
>
>>I think the newbie way of thinking of blocks is indeed the more 
>>natural one, than viewing it from the VM implementation side.
>>
>
>Yes. It's also the way to think about them at the language level. 
>The VM is the implementation level and often it's job is to hide 
>much of the details of the inner workings from the user and the 
>language itself. That is why I prefer giving the language priority 
>in driving the design over the concerns of the virtual machine 
>implementation issues (if at all possible).
>
>
>>
>>>It's nice to move the discussion forward with someone who gets it for a
>>>change.
>>>
>>Thanks.
>
>Your welcome.
>
>>If I remember correctly Ian Piumarta does (somehow) similiar things 
>>with his Id Smalltalk variant.
>
>Yes, Ian's work is really amazing.
>
>
>>I believe, he adds blocks to classes as named methods, too. So I've 
>>got these ideas from him... *g*
>
>I did share my thoughts on the unification of Blocks and Methods 
>with Alan Kay and Dan Ingalls a few years back; as well I've 
>mentioned it at OOPSLA and in private conversations with various 
>people. Alan or Dan may have mentioned it to Ian or I might have 
>mentioned it to Ian at OOPSLA (I don't recall if I spoke with him 
>there). Or maybe others thought of it before. We have to ask Alan, 
>Dan and Ian about their coming to the idea. After telling Allen 
>Wirfs-Brock about it a few years back he said he'd come across that 
>idea before but that it seemed that no one did anything with it. So 
>I don't claim ownership of the idea (other than co-originating it) 
>but I do promote it vigorously since I see it's value. It's also not 
>a big leap to make as Block and Method syntax is almost the same - 
>the big leap is seeing it's value.
>
>Part of it's elegance is that it's such a minor change to make the 
>unification happen and that it has such a powerful new dimension 
>opening impact!
>
>If a change is required in syntax and it doesn't open a whole new 
>dimension of extensibility as a result then chop it out. It's like 
>Tilera's "kill design rule" for their N-Core chips (Tile64 or TileN) 
>where a N% increase in surface area of the chip must increase 
>performance by an equal N%!  I apply a similar set of "design kill 
>rules" for syntax changes to Smalltalk and ZokuScript. If it's not 
>message based using existing syntax then I ask "how can it be made 
>to work with messages?" - this was the line of thinking that lead me 
>to see that all meta data and meta operations can be accomplished 
>with the existing unary, binary and keyword messaging syntax. That 
>was a breakthrough! It also means that almost all changes in syntax 
>are not needed as most changes are attempts to add meta data or 
>operations. The problem with new syntaxes is that they break the 
>notion of one uniform messaging syntax and make the world much 
>harder. This makes advanced topics such as code analysis and code 
>rewriting much more difficult and cumbersome since multiple syntax 
>forms are involved and they may not have bidirectional 
>transformations available when being converted this way and back that way.
>
>I see the elegance and beauty of a unified block and method syntax 
>for Smalltalk and ZokuScript such that I'm promoting it in the 
>Smalltalk community. Certainly it will end up in ZokuScript as it's 
>an essential building block for the future that I see for Smalltalk 
>like or Smalltalk inspired systems.
>
>If we as designers of a computer language (or other software 
>programs) fail to bring the principles of elegance, beauty and 
>simplicity to the language (or program) design and the design 
>process then how can we expect our products to be powerful or users 
>to be elegant, use beauty and simplicity in their expressions with 
>our languages and tools we make?
>
>All the best,
>
>peter
>
>
>
>
>
>