>This may solve the do/value()/send problem. PLEASE FIND HOLES IN IT!
>
> a) Once a variable is a temp, it may not later be redefined as a
> non-temp
>
> b) Temps all expire at the end of the line, if not before [always has
> been this way]
>
> c) Each evaluated do/value()/send gets its own set of temps to play
> with, hopefully avoiding the eval() conflict.
>
>PLEASE try and find problems with this. Attack it from every angle
>possible. Because this is what's going to go into the Interpreter, and if
>it's wrong, the results will be, too.
>
>This will add some significant complexity to Interpreter, but everyone
>seems to think it's work it. And it won't give a 20% speed hit, either.
>
>The do and send commands and the value function will still be slow, however.
Anthony,
a and b are how it happens in many interpreters. This ought to work. How
do you want to give "do" its own set of temps? Could you elaborate how your
interpreter handles temporaries so I can understand the repercussions?
Anyhow, I think it's no problem that do and send will be slow. For 2.0
we'll tackle providing faster alternatives (e.g. like Serf's unquoted
"send").
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
