I do not approve of naming variables at runtime for some very sound
technical reasons. Remember that the interpreter will convert all variables
to variable numbers.
Too see why, I'll show some examples:
Ex. 1: put 1 into var0 A really simple case. 1 is loaded into pos 0,
put var0 into var1 then pos 0 into pos 1. No big deal, no
trickery.
Ex. 2: put 1 into var0 A little bit of trickery. The first
put 2 into var1 two lines are easy example one stuff,
put var0+var1^2 into var2 but the third line brings a little bit
of mess: A temporary must be used to
store the result of var1^2. (OK, in
this case it could be optimized out,
but not in most cases)
And the first two examples are how I'd like to have things work. But some
people want a do command and a send command. Ak. Proceeding:
Ex. 3: put 1 into var0 This can be compiled without too
much send "a var0" to cd fld 1 trouble: Generate a
function call to
"a" belonging to card fld 1.
Ex. 4: put 1 into var0 Third line contains the first mess.
put 1 into var1 In order to evaluate the third line,
do "answer"&&var0&&"with"&&var1 the compiler must generate a hell of
a lot of temps, generate string
concatenation code to put the
command together, and then manage to
call NuParser. It must also handle
possible errors -- what if var0 were
two words, or a single quotation mark?
And passing the environment is just
hell.
OK, that was the hard stuff. Now the impossible:
Ex. 5: do "put 1 into var1" First, this will be compiled. Slot 0 will be
... assigned to var1 on line 2. And slot 1 to
put var1 into var0 var0 [don't ask]. However, they will not
answer var0 exist until line two, and until then those
slots can be used by temps.
Script starts executing. First thing that
happens is the do command. This causes a call
into NuParser to parse it, then a compile
of that one line. The compiler sees slot 0
is reserved for var1, and uses it for the
do command. All is well, until somewhere in the
"..." a temp is used -- demolishing the value
in slot 0, because slot 0 should of been free.
Then line 3 comes, and that's the end of any
valid results.
There are verious other scenarios simular to five that are more intricate,
and harder to work around. In five, Interpreter could just be told not to
re-use temps for other variables, though this is quite inefficient. And
these little messes make optimization -- something I'd eventually like to
add in -- a LOT harder.
If I _absolutely_ must add in a do command, I'm tempted to:
1) Switch to either Uli's Velocity or Joker as an alternative
interpreter. I don't know which can support this easily, but
I doubt as if either will be as fast [no insult intended]
2) Switch to a pure interpreter, interpreting straight off of
the bytecode, without compiling; this will be slower. Not sure
how it will compare to Joker.
3) Spit out a funny warning, along with description of the problem,
URL to this message or a successor in the mail archive, and then
use either #1 or #2
But in any case, this means maintaining two interpreters, which is QUITE
stupid in my opinion.
The do command is like writing a C program which as part of its normal
execution generates some C source code, calls gcc, links the result,
ececutes the result of the linker, pipes it's core and variables to the
process, and then reads a new core back from that process. It is almost as
evil as the secant.
