You may also want to be able to short circuit some of the steps.
Especially where the startup time may outweigh the win of optimization.
And if there could be different execution engines. Machine level,
bytecode, (and perhaps straight out of the syntax tree.)
Hmm, might that make some debugging easier?
<chaim>
>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The structure I've been thinking of looks like:
DS> Program Text
DS> |
DS> |
DS> |
DS> V
DS> +--------------+
DS> | Lex/parse |
DS> +--------------+
DS> |
DS> Syntax tree
DS> |
DS> V
DS> +--------------+
DS> | Bytecoder |
DS> +--------------+
DS> |
DS> Bytecodes
DS> |
DS> V
DS> +--------------+
DS> | Optimizer |
DS> +--------------+
DS> |
DS> Optimized
DS> bytecodes
DS> |
DS> V
DS> +--------------+
DS> | Execution |
DS> | Engine |
DS> +--------------+
DS> With each box being replaceable, and the process being freezable between
DS> boxes. The lexer and parser probably ought to be separated, thinking about
DS> it, and we probably want to allow folks to wedge at least C code into each
DS> bit. (I'm not sure whether allowing you to write part of the optimizer in
DS> perl would be a win, but I suppose if it was saving the byte stream to disk...)
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
