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