Josh Grams <josh@[EMAIL PROTECTED]
> wrote:
> I've been thinking about Jonah Thomas's comment (back toward the
> beginning of this month) that there is a bunch of unnecessary
> complexity around IMMEDIATE/POSTPONE/etc and the divide between
> interpretation and compilation semantics.
>
> Coming mostly from languages other than Forth, it seems to me that
> the complexity comes from Forth offering the wrong choice to the
> programmer. I *think* that what I normally want as a programmer
> is a distinction between syntax and semantics (parse time and
> "run" time).
>
> For instance, I want the behavior of S" to be: parse a string
> delimited by a double-quote, and add a string literal to the
> current "statement", regardless of whether or not I'm inside a
> definition.
>
> : CHAR PARSE-WORD DROP C@[EMAIL PROTECTED]
LITERAL ; SYNTAX
> : S" CHAR " PARSE SLITERAL ; SYNTAX
What you're proposing has been championed by various people, notably
John Doty. Instead of having a separate interpreter that parses a word
at a time and executes them on the spot, you compile a line at a time
(or some other sequence) and then either save the code for later or else
execute it and discard it.
Various people have tried out this approach. Many of them have concluded
that this is simpler some ways, but it moves the complexity into other
places rather then actually reduce that complexity. I don't know how
much of the complexity is things that are required by standards but not
actually needed. It might be simpler to always compile and then simplify
away other things instead of add complications so you can keep them. I
don't know.
> It would, of course, add a bit of complexity to the compiler. But
> I think it simplifies things for the programmer. And it has the
> advantage that each name only ever has one piece of code attached
> to it. And I believe you could have ANS compliance with basically
> just:
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.
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.
And .... POSTPONE IF .... sometimes we want to take a command that
would normally happen now and make it happen later.
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 it's possible to get all the results you'd want that way. Like,
you could have a system to start a new temporary line, and the new one
executes before the old one. So you could do
['] FOO
on a separate line and have it get compiled and then execute to compile
FOO's xt as a literal in the previous definition, and then go back to
compiling the unfinished definition. Each individual line would get
compiled into the currently-unfinished code or compiled into its own
routine that gets executed first, depending on which you tell that line
to do. I started to implement this and got distracted with an income
opportunity and haven't gotten back to it.
But usually people who build always-compile systems accept less
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.
|
