Hi Martin,

Martin Beck wrote:
> Am Donnerstag, 13. September 2007 22:00:55 schrieb Peter William Lount:
>   
>> Hi,
>>     
> Hi, first I want to say, that I'm thinking of the same ideas that you think of 
> and I really like the [a. b. c.] values idea.
>   

Excellent. Birds of a feather flock together!


>   
>> [
>>      Object subclass: #Person.
>>
>>     Person
>>         addInstanceVariable: #firstName;
>>         addInstanceVariable: #middleName;
>>         addInstanceVariable: #lastName.
>>
>>     "Block form."
>>     Person addInstanceMethod: [firstName: aString | firstName := aString ].
>>
>>     "Same method as the line above, in method form this time."
>>     Person addInstanceMethod: [
>>         firstName: aString
>>             firstName := aString
>>     ].
>>
>>     
> 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. 
This sort of minor syntax change is acceptable since it moves Smalltalk 
towards a more powerful future with capabilities that are essential in 
competing with other languages and in expressing new programs 
eloquently. This sort of change has happened with blocks when variables 
were added to them and other minor changes by different vendors to 
blocks over the years. Syntax that adds new characters such as "{" and 
"}" needs to be very seriously considered especially when it's adding 
capabilities in fixed ways that aren't extensible and that violate the 
message passing paradigm.


> at least as far as I know ST80... ;) . I would prefer something 
> like this:
>
> Person addInstanceMethod: [ :aString | firstName := aString ] named: 
> #firstName:
>   

Yes, that is valid and possible in a unified block and method syntax.


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


> That it is internally compiled to some bytecode sequence _not_ necessarily 
> representing the different statement borders is just an optimization for the 
> sake of speed. Howerver, instead of byte code I'm dreaming of some kind of 
> AST... Be aware, that you can represent any tree data structure with a 
> sequential array resulting in just another form of "byte code". ;)
>   

Yes, the whole issue regarding statement boundaries not being present in 
existing Smalltalk byte codes or natively compiled code is strictly a 
code optimization. If statements boundaries are needed then they need to 
be compiled in for code that needs it even if that code needs to be 
compiled and optimized on the fly. The Self Language has done this very 
effectively having five or six different versions for a method (or just 
as easily a block).

It's nice to move the discussion forward with someone who gets it for a 
change.

All the best,

Peter