Josh Grams <josh@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethomas5@[EMAIL PROTECTED]
> wrote:
> > I think we're on the same wavelength here but I've been fooled
> > before sometimes when I thought that about others.
>
> Ditto. :)
>
> > 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.
>
> I think you need to compile to a temporary buffer if you're going to
> execute and discard it. e.g. what if the code adds stuff to the
> dictionary?
This is tricky, but maybe that would work out. If your literals etc put
addresses and such on the stack, and then you act on them afterward,
then by the time you add stuff to the dictionary you've already executed
it. Say you had a string literal and you want to compile that. You move
the string literal to the left, and everything it overwrites has already
executed. You should be fine as long as you don't try to execute it
again after it's clobbered. Tricky. There could be a gotcha I haven't
thought of.
> > I believe this doesn't actually save you a whole lot (though 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 compiler versions, so that is a saving.)
>
> Sure. The only time that I think it saves you trouble is when
> defining words with special compilation semantics. You don't have to
> write two versions, like CHAR and [CHAR]. You don't need
> interpret/compile: and dual xt dictionaries to try and get the
> functionality under one name. You just define the compilation
> semantics and make it IMMEDIATE, and it works properly whether or not
> you're in a definition (I believe).
One word that does one thing, the same inside definitions or not. That's
a fine goal. It makes things simpler for newbies. The whole compiler is
simpler unless you need to do something else more complicated to
compensate.
> > You get to use control structures outside of definitions, provided
> > they're all on one line. That's an advantage too.
>
> With the way I'm thinking about implementing it, they can be on
> multiple lines, provided that a complete control structure fits into
> the temporary compilation buffer.
So instead of executing a line at a time, you have some signal that says
it's time to execute? That's a complication but it could be worthwhile.
> > 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 ?
>
> Hrm. I hadn't thought of that one. So you probably can't use
> compile-only as an implementation technique for a completely standard
> Forth.
Various people have claimed that if you try to implement all the
standard features on top of a compile-only system, you get lots of
complexity when you make them, and it's as bad as the complexity of an
interpret state. I don't remember the details now about what causes that
complexity. You could hope to make a nonstandard system that provides
simple ways to do all the complicated things we do now.
> But I don't think anyone ever interprets >IN directly anyway.
> Searching the gforth-cvs sources turns up only occurrences that are
> compiled into a parsing word. So it just means that any word which
> does parsing needs to be declared as a parsing (immediate) word.
That could work out, then. To be standard you'd want to allow [ .... ]
which is kind of like turning everything inside the brackets into
immediate words. You talked about compiling that inside stuff into a new
buffer. If it's a new buffer full of compiled code you could let >IN
stay the same.
|
