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