At 8:00 AM -0700 on 12/3/99, Rob Cozens wrote:

>A few thoughts beyond my original "how can I do without those capabilities?":
>
>* Anthony, is this because --
>
>  A.  The capabilities would be inefficient if implemented,
>  B.  Implementation of these capabilities would negatively impact overall
>performance (eg: implementing send slows all message passing), or
>  C.  Something else (please explain)?

A & B definitely apply. C also does -- it would be hard as hell to get them
into the interpreter.

I'll try and explain why. The interpreter is not a classical interpreter at
all. It is more accurately a compiler and an emulator joined together. I'll
give an example, as it will apply to the new interpreter. Remember that the
new interpreter does not yet exists, so this is a just a plan. But the old
interpreter works in a very simular way. Take an example script:

        function x a,b
                put a*(b+2*a) into c
                answer c with "OK" or "Cancel"
                return it
        end x

This will be passed to the parse, then to the tokenizer, then to the
compiler, which will spit out:

        ; Take note! The numbers refer to variables (unless proceeded by a
        ; number sign). Variables are as follows
        ; (this is not acutally part of the compiler output!)
        ;
        ; a = 0
        ; b = 1
        ;
        ; I'm inserting these comments to make it easier to read

        pop 1           ; load parameters into variables
        pop 0

        load 2, #2      ; TMP1 = 2
        mul 3, 2, 0     ; TMP2 = 3
        add 2, 1, 3     ; TMP1 re-used; TMP2 now unused
        mul 2, 0, 2     ; WATCH OUT! TMP1 is now c.

        push 2          ; Push c, begin call to answer
        push.s 0        ; String table entry 0, "OK"
        push.s 1        ; String table entry 1, "Cancel"
        call 2          ; String table entry 2, "answer"

        end             ; return. Don't need to push result onto stack
                        ; because answer already did that.


You'll notice that there is about no way to get a 'do' command, a
runtime-named variable, etc. into that. It is possible, however, to use
hashes for the runtime-named variable effect. And hopefully, NuTalk will be
powerfull enough you won't need a do command.

I don't mind code written at runtime; I do mind it sharing environment with
the code that writes it. If you want a do command like a function call
(i.e., respects local variables), fine, that's doable.

Reply via email to