Re: The IMMEDIATE mess


Andrew Haley wrote:

The complications of state-smart etc don't belong in the words
themselves.

Semi-seriously: The complications of state-smart don't belong
anywhere. Give it up; you'll feel much better. :-)

I agree with you about state-smart words. Having two behaviors for one
name is almost as bad as using two names for one behavior. :-)

I don't see how making state even more complicated is likely to
simplify anything.

Well, I wanted to include the common practice and add something new so
it wouldn't have to break existing code. Doing that almost inevitably
means adding complication -- you can't get rid of the existing garbage
but can only add something new and (hopefully) better.

Wordlists don't clean up the IMMEDIATE mess, they make more messes
attempting to solve that. IMMEDIATE affects FIND . State-smart words
don't work because they try to fix something that ought to happen
while parsing with something that happens at execution time --
whenever execution happens.

I don't really understand this. Immediate words are precisely those
words that always execute while parsing, whether in compile or
interpret state. I wonder: are you trying to do something especially
exotic with a complicated syntax?

Once you get rid of state-smart words, the only value you get from
immediate words are a few anomalies like ( . A small handful of words
that you want to do exactly the same thing whether you are compiling or
interpreting. You do better to treat almost every immediate word as
compile-only, as an addition to the compiler.

Immediate doesn't do the job right, but it's adequately usable by
people who just want to get their work done. Use it wrong and it might
bite you, and then you'll notice you used it wrong and fix the problem.
If you try to write portable code you might not notice immediate
mistakes until you port to a standard system which does things
differently from your system. At that point you can notice the problem
and fix it.

The real problem here is for people who want to build portable tools.
Say I make something that looks like a nice simple tool, that ought to
be portable to most standard Forths. I put it up here and somebody says
"What about this weird trick here, somebody can do this peculiar
programming trick and your tool will break." So then I jump through
more hoops, and the weirder the programming tricks we're willing to
consider the higher and smaller the flaming hoops get. At some point it
makes sense to just declare an environmental dependency on systems that
do what I need them to, and trust that programmers whose tricks aren't
too weird might have a use for the tools.

But I want to find a way to handle this particular problem. It looked
to me like we'd get a lot of freedom for standard programs with
POSTPONE . You could extend the compiler any way you wanted, portably.
State-smart words are potentially confusing, but there was the chance
to redefine any word as state-smart, and give it whatever extra
behavior you wanted and if you did it carefully, all the extra things
would be invisible to standard programs unless they knew just how to
look. But it turned out to be kind of a mirage. The STATE/IMMEDIATE
system didn't allow quite that much flexibility, when it also had to
fit in with the flexibility of EXECUTE and COMPILE, as well as
[COMPILE] and POSTPONE . By the time you add in the whereases and
yesbuts needed to allow various legacy systems to be standard, it turns
into what John Doty would call language lawyering. It's so much better
to have simple tools that do the same thing all the time, than simple
tools that work right up until you do something unusual and then they
break in some unusual way. And that's better than complicated tools
that have lots of complicated alternative behaviors for special
circumstances, that are likely to break in unusual ways when you least
expect them to.

My idea of having FIND (or the next word) give you more information may
seem like it's too complex. I don't see any way to make it real simple
and still keep the old STATE/IMMEDIATE stuff too. I'll keep looking.

.

Relevant Pages

  • Re: The IMMEDIATE mess
    ... trouble with this kind of argument is that it doesn't take very long ... Any word you compile a STATE-smart word into becomes STATE-smart ... The idea that we mustn't provide tools to programmers because they ... to avoid STATE-smart words -- they've tried it and gotten burned. ...
    (comp.lang.forth)
  • Re: RfD: SYNONYM
    ... : SYNONYM ... BL WORD FIND DROP COMPILE, ... POSTPONE;; ... You need two behaviors that will each happen at ...
    (comp.lang.forth)
  • Re: class smart words
    ... the central problem with state-smart words is that the decision ... Also there's the question of its execution ... But when it's the compiler making that choice based on its ... with two behaviors. ...
    (comp.lang.forth)