Josh Grams <josh@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethomas5@[EMAIL PROTECTED]
> wrote:
> > 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.
I think we're on the same wavelength here but I've been fooled before
sometimes when I thought that about others.
Let's see. Compile-only. You compile each line and then either execute
it and discard it, or you leave it added to the dictionary.
But you want to have immediate words that execute during compilation.
And the same words would execute during interpretation, the only
difference is that it's code that will be executed and thrown away
instead of saved.
I believe this doesn't actually save you a whole lot (thought I could be
wrong). Forth already has immediate words that execute whether
interpreting or compiling. And it already has regular words that execute
in an interpreted line and get compiled in a compiled line. So you need
interpreted parsing words to parse and save strings that then get acted
on later, more complex. (But you could throw them way and use the
copiler versions, so that is a saving.) You get to use control
structures outside of definitions, provided they're all on one line.
That's an advantage too. When an execution token executes, you're always
at the end of a line, right? So >IN @[EMAIL PROTECTED]
will always give the same as
SOURCE NIP ?
I thought of a way to use that last thought. You could have essentially
no immediate words. When you have an immediate word, you compile it as
usual and it executes when its line executes. So parsing words would
always parse the next line. Simple.
......
[']
MY-DEFINITION
......
Newline for each parsing word, newline for each control structure word,
you wind up with prettyprinting kind of like Python. No immediate words.
No STATE, one way or another you decide whether each line should be
compiled-executed-and-discarded or just compiled. All simpler, but you
have a lot of short lines.
> >> 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,
If you get the chance sometimes, you might look at John Doty's LSE64. He
does something a lot like you want, and he swears by it. If you like it
I'm sure he'd appreciate somebody paying attention to it.
|
