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?
> 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.
Yup.
> 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).
So maybe not a big win, but I think it's a worthwhile goal.
> 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.
> 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.
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.
> 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.
Yeah, I've looked at LSE64. But it's designed so as to have no
immediates at all. I think that being able to define new syntax is a
very useful tool, and I don't have a problem with standard Forth
(mostly). I just think that when you want the "same" functionality in
both interpret/compile mode, it's silly to have to do things like:
: CHAR BL WORD C@[EMAIL PROTECTED]
;
: [CHAR] CHAR POSTPONE LITERAL ; IMMEDIATE
That, in my opinion, is something that the language should do for you.
But it looks like you can't do it without breaking a fair bit of
compatibility. It might be a fun experiment anyway...
--Josh
|
