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