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. Your 
syntax change does early binding of a name to an implementing Block, which we 
don't want in Smalltalk... :) 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).
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. ;)

> > 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.
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 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. 
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.
I think the newbie way of thinking of blocks is indeed the more natural one, 
than viewing it from the VM implementation side.

> It's nice to move the discussion forward with someone who gets it for a
> change.
Thanks. If I remember correctly Ian Piumarta does (somehow) similiar things 
with his Id Smalltalk variant. I believe, he adds blocks to classes as named 
methods, too. So I've got these ideas from him... *g*

> All the best,
>
> Peter
Best regards,
Martin