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.

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

> > (*) just on this point I'd prefer to write something like
> > {[a]. [:x| x b]. [:x | x c]} valueAsChain
> >
> >
> What would this evaluate as and how would it evaluate? Would each
> element of the collection be evaluated as a block and passed in the
> value from the previous element?

yes.

-- 
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org