At 10:29 PM +0100 on 12/1/99, M. Uli Kusterer wrote:

> I'm not the one writing the interpreter, but so far it looks like OpenTalk
>will exist as an interpreted or "virtually compiled" language on its own
>first. We will then later "tack on" fields, buttons etc. I'm not sure it
>will be feasible to maintain fields and buttons as completely separate from
>the interpreter, but I don't think that it would be much trouble to stick
>with OpenTalk for now, and to fork when it's finished, remove the field and
>button stuff and then add any new object types you'd want.

Heck, I'll let him use a define in a config file to remove them if he
wants. It's hardly any work.

>
> If it's a compiler you want, it'll get a bit more complicated. Then you'd
>probably also have to rip out the execution stuff of interpreter and just
>use the tokenizer and parser and write the code to generate assembly
>instructions yourself.

The interpreter will have a few entrypoints. This is what one for saving
scripts will look like:

        ... (get script)
        NuInterpreter::XPlat::TokenHandle tok =
                NuInterpreter::NuTalk::parse(script,
                                             NuInterpreter::NuTalk::tokenize);
        ... (save tokenized form)

The one for running scripts will be like:

NuInterpreter::NuVar NuInterpreter::Run(NuInterpreter::XPlat::TokenHandle tok,
                                        NuInterpreter::XPlat::ScriptID id) {
        ... (check if cached versions of compiled scripts are
             availible. If not, compile the world)

        // Check if tok is cached
        NuInterpreter::CompiledScriptHand comp;
        if (... cache entry exists ...)
                ... (load cached)
        else
                comp = NuInterpreter::NullCPU::Compiler(tok);
        return NuInterpreter::NullCPU::Run(comp);
}

All you'd have to do would be to write the following:

        NuInterpreter::NativeCPU::Compiler
                Put the tokenized form through a real compiler. Perhaps
                gcc.

        NuInterpreter::NativeCPU::Run
                Write an executable based on the real compiler's output.
                Perhaps this would run the linker.


>you'd
>need strong data typing and other things if you'd want to write an INIT,
>which will probably not get into OC.

You don't really need strong data typing, and apparently he does not want it.

Reply via email to