Re: The IMMEDIATE mess

J Thomas <jethomas5@xxxxxxxxx> wrote:

Andrew Haley wrote:
J Thomas <jethomas5@xxxxxxxxx> wrote:

I'm still baffled by what it is you want to be rid of.

I'll try again.

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.

OK. It seems to me that IMMEDIATE does this job quite well already:
if you have a word that only makes sense in compile state (e.g. IF,
WHILE, etc) then what is wrong with IMMEDIATE ? IMMEDIATE has just
one job to do.

IMMEDIATE is adequate to a lot of tasks. If you want a word that only
makes sense in compile state, then you can make it with IMMEDIATE . And
you can use your innate good sense not to use it except in compile
state.

If you want the same name to show two different behaviors, one in
interpret state and one in compile state, pretty much your only
portable choice is to write a state-smart word with all the
disadvantages that come with that.

Right. So, if you simply don't use STATE, then you can't do that, and
the problem goes away.

There are two kinds of disadvantages to state-smart words. One kind
comes from the way you have to implement it. The word decides for
itself at run-time what to do, and for some purposes that's the wrong
time to choose. The other kind of disadvantage comes from having one
name with two behaviors. I say that sometimes it's worth it to deal
with the second set of disadvantages. You deal with those problems
every time you put two words with the same name in two different
wordlists. But then you aren't choosing at runtime, you're chosing when
you lookup the word.

If you never want one name for two behaviors, then there's no
problem here.

Right; problem solved.

If you might sometime want one name with two behaviors, different
for compiling versus interpreting, then you're more likely to want
to choose when you lookup the word and not at runtime. IMHO. But
there's no standard way to do that. Lots of people have
implementations similar to Mark Humphries' approach, and they
work. Practically everybody has ways to extend their
interpreter. But there's no way for a standard program to do either
of those.

I'm sorry, this is all too abstract for me. I guess I don't
understand what the problems are you're trying to eliminate; in the
absence of any examples I have no way to know. I know what I think
should go: STATE. At the time of ANS, Forth, Inc already had
well-established practice for a STATE-free Forth, but STATE went into
the standard anyway.

Get rid of STATE and IMMEDIATE and probably my concerns will come
out in the wash. But it's hard to get rid of things that have been
standard for a long time. Get rid of IMMEDIATE and you break every
line of standard code that has an IMMEDIATE in it. (Unless the new
way lets you define IMMEDIATE portably.)

No, just get rid of STATE. The great thing about programming in a
STATE-free Forth (or, at least, one in which STATE is invisible) is
that all your code can still be ANS standard Forth programs. All you
have to do is never use STATE.

I'd like to emphasize that the problem is not STATE per se, but having
words that -- as you put it -- show two different behaviors, one in
interpret state and one in compile state.

FORTH, Inc used their STATEless Forth for many years, with no
application problems of which I am aware. STATE had to go back in to
their products order to be ANS compatible.

When there's only one way to solve a problem, programmers know what
to do. When there are two ways they're never sure. It could be
argued that a Forth standard should give programmers firm limits so
they'll just get their work done and not be tempted to find
brilliant tricky solutions that give the language a bad
reputation. Don't let them extend the compiler. Standard code should
all be written the same way and it should all be application code.

No, extending the compiler is good. You don't need STATE to have an
extensible compiler.

Andrew.
.

Relevant Pages

  • Re: LC53 statistics
    ... POSTPONE; may just be SMUDGE R> DROP, ... POSTPONE DUP POSTPONE; IMMEDIATE ... standard Forth programs will not run on it. ... interpret state and compile state. ...
    (comp.lang.forth)
  • Re: The IMMEDIATE mess
    ... Usually what we need is not IMMEDIATE words or state-smart words. ... Any word that includes POSTPONE or executes COMPILE, ... The issue doesn't come up after you execute the words. ...
    (comp.lang.forth)
  • Re: RfD: SYNONYM
    ... BL WORD FIND DROP COMPILE, ... POSTPONE;; ... To be on the safe side it might make sense to make it immediate after ... Etc. Getting the standard ...
    (comp.lang.forth)
  • Re: The IMMEDIATE mess
    ... You do better to treat almost every immediate word as ... makes sense in compile state, then you can make it with IMMEDIATE. ... But there's no way for a standard ... If you give Forth programmers power, ...
    (comp.lang.forth)
  • Re: The IMMEDIATE mess
    ... makes sense in compile state, then you can make it with IMMEDIATE. ... In 35 years I've yet to have a problem with IMMEDIATE. ... So I want to find a way to add the features I want instead of get rid ... If you give Forth programmers power, ...
    (comp.lang.forth)