On 2008-03-23, Jonah Thomas <jethomas5@[EMAIL PROTECTED]
> wrote:
> Josh Grams <josh@[EMAIL PROTECTED]
> wrote (more or less):
>
>> What about parse/execute instead of interpret/compile?
> ...
>> It would, of course, add a bit of complexity to the compiler.
>
> It isn't necessarily more complex for the compiler. But you have to
> think -- sometimes we want to parse strings and do something to them in
> midline.
>
> ... [ ' DUP ] LITERAL ....
>
> ... ['] DUP ....
>
> It isn't enough to tell the compiler to compile strings into the current
> word. There are other things to do with them.
>
> Print a string now. .(
> Print it later. ."
> Get an xt [']
> Get a character [CHAR]
> Maybe print and abort later ABORT"
> Ignore the string now (
> Etc.
Sure, but all those can be handled just as they are in a standard Forth,
with the exception that they also work in "interpretation state".
Syntax words are just immediates. In fact, they are precisely the
compilation semantics of Standard Forth. The only thing that's
different in a compile-only scheme is that you don't have the
"optimized" version for interpretation state which performs the action
or leaves the values on the stack instead of compiling code to do so.
> And then there's
>
> [ do-something-now ]
>
> Sometimes we want to execute anything right now, not later when the line
> executes, but now before the rest of the line has compiled.
Right. Obviously you have to flush the temporary buffer (execute its
contents and empty it) whenever you switch to compilation state. I was
planning on flushing it at the end of every line (unless there are open
control-flow constructs), but you could do it after every word, or when
the buffer gets full, or whatever.
> And .... POSTPONE IF .... sometimes we want to take a command that
> would normally happen now and make it happen later.
POSTPONE would be specified just as it currently is: "Append the
compilation semantics of name to the current definition." Which means
compile a call to the code for syntax words, and compile 'xt COMPILE,'
for normal words.
> You want to build all this into the compiler, and also make the compiler
> extensible? I have some doubts. It isn't trivial to always-compile and
> still do all the things we're used to doing. Somehow you have to decide
> what to give up.
I think of it as being like caching; it (mostly) doesn't change the
semantics, it only changes when the actions take place. So I don't
anticipate losing functionality.
>> I haven't implemented this, and of course I've skipped all the
>> details here; I just wanted to present the basic idea. Thoughts?
>
> You're in good company. A lot of good people have tried it out and
> decided it wasn't worth doing, but some have kept going with it.
Hrm. That's a bit discouraging. But...I had thought of *almost* all
the examples that you brought up, and can see how to handle all of them.
Unfortunately I don't have much spare time; spring is coming and farm
work is starting to take over every available minute. But I do have the
bare bones of a Forth-in-Forth interpreter; maybe I can adapt it and do
a quick prototype so I can check it against the Hayes' suite and Anton's
POSTPONE tests to see where it goes wrong.
Thanks for the background,
--Josh
|
