On Mar 23, 10:50 am, Josh Grams <j...@[EMAIL PROTECTED]
> wrote:
> 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.
But if you are within a definition, then you want to put it in
permanently allocated dataspace associated with that codespace,
whereas if you are interpreting, there is generally no need for it to
be permanent nor any need for it to be associated to any code-
space ... unless you are going to be handing it to a word that has a
defining word as a factor, so that it can perform something like ``...
2>R : 2R> SLITERAL ...''.
.... so you really don't want *the same thing*, you just want something
that "does the same kind of thing".
And yes, I remember the days of the state smart >R and R> that
compiles a push to the return stack while compiling and a push to a
explicit auxilliary stack when interpreting ... but in the end, its
normally better to have the words that you are using when bench
testing work exactly the same when they are executed in the
interpreter as when they are compiled and then execute in a word.
Indeed, that whole convenience of copying and pasting from the history
file to the source file once you get to what seems to be working
right, and then testing that word in more depth to make sure ... if
you have too many cases of, "well, it does not do *exactly* the same
thing executed by the interpreter as executing inside a word" ... you
start to lose that convenience.
> It would, of course, add a bit of complexity to the compiler. But
> I think it simplifies things for the programmer.
There are some things that adds complexity to a compiler that can
simplify things for a programmer ... for example, when faced with a
need to use the top of the stack like a C stack frame, having locals
simplifies things. While there's no point in designing that need into
your program, sometimes its there at the low level of your program in
the nature of the problem.
But often, things that add complexity to a compiler are things that
make the simpler problems simpler and the harder problems harder.
State smart IF-ELSE-THEN was like that ... having conditional
interpretation was great, and then you find that you want to use the
conditional interpretation when compiling, and then you wrap the
interpreted IF-THEN-ELSE into immediate [IF]-[ELSE]-[THEN] being
careful to convince the state-smart IF-ELSE-THEN that you are really
interpreting, and then restarting the compiler when you are done ...
and now it launches the compiler if you use that when interpreting, so
the immediate compiling wrappers retrieve the previous state and
restores it just so they can lie to the state-smart IF-ELSE-THEN words
about whether it is compiling or interpreting ...
.... and finally, if you do get [IF]-[ELSE]-[THEN] working correctly
with state-smart IF-ELSE-THEN ... you realize that just immediate [IF]-
[ELSE]-[THEN] and compile-only IF-ELSE-THEN give you what you need,
without any state-smartness.
I don't know if there is any game to be found in the terrain that
Jonah is hunting in, to make for a simpler system, but he's a lot more
likely to hunt up something that will make Forth simpler to program by
making it simpler than the strategy of making it simpler to program by
introducing more complexity.
|
