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
|