Fear and loathing of the "perification" of Smalltalk

Peter William Lount peter at smalltalk.org
Tue Sep 4 23:51:16 UTC 2007


Damien Pollet wrote:
> On 05/09/07, Peter William Lount <peter at smalltalk.org> wrote:
>   
>> No, the changes wouldn't be any more complex than what was done for
>> curly braces except for adding the parameterization of the passing in of
>> the collection that you want the results to flow into (including streams).
>>     
>>> To me a. b. c really means "evaluate a then b then c and return the result of c".
>>>       
>> For normal default evaluation yes.
>>     
>
> Problem is, the evaluator is the VM and all it sees is bytecodes. It
> you want to change the evaluator you have either to change the
> bytecodes (instrument the block to keep intermediate values) on the
> fly or make a case statement in the VM.
>   
That may be the case depending on the byte codes. Note that not all 
Smalltalk implementations use byte codes.


>   
>>>  - fix the block optimisations, because now they are just sequences of
>>> expressions with undefined a-priori semantics
>>>
>>>       
>> Could you illuminate more on this, I'm not sure what you mean.
>>     
>
> Currently the compiler compiles blocks to bytecodes for the statements
> + a context object. If you want to choose evaluation semantics
> depending on a message send, then that message send has to recompile
> the whole block to bytecodes that match the required semantics. All
> you can do before that message send is store a sequence of
> expressions.
>   
Please provide a much more detailed example.



Cheers,

Peter




More information about the Squeak-dev mailing list