Re: The IMMEDIATE mess

Alex McDonald wrote:
Elizabeth D Rather wrote:
J Thomas wrote:
....
...

It's possible I want things I shouldn't want.
Entirely possible. It seems to me that you're being excessively
theoretical in imagining problems where none exist on this issue.

I can't see why you claim "Tom Cruise-type hot-shots" are the only ones
interested in getting this to work. Documenting immediacy was something
that the ANS Forth committee went to great lengths to eliminate
(section A.6.1.2033 POSTPONE);

<quote>
COMPILE was designed to be applied to non-immediate words and [COMPILE]
to immediate words. This burdens the programmer with needing to know
which words in a system are immediate. Consequently, Forth standards
have had to specify the immediacy or non-immediacy of all words covered
by the Standard. This unnecessarily constrains implementors.
</quote>

What makes state-smart words different? If my implementation of word X
can't be POSTPONEd correctly because it's state-smart, but your X can,
that seems to me a fundamental burden on the programmer much worse than
the immediacy problem the standard fixed, as the list of words can very
from system to system -- and they can all still claim ANS compliance
without documenting them. I for one see it to be a problem worthy of
discussion. If serious professionals think otherwise, I'm baffled as to
why they might consider program portability and correctness an optional
feature. Enlightenment, please.

Well, JET, Andrew, and I have all agreed that state-smart words are best avoided. The few that survive in the standard that may cause trouble (e.g., TO) have warnings against POSTPONEing them. IMO if you have implemented some standard word in such a way that there are extra restrictions on it (e.g. it isn't POSTPONEable) you should document those restrictions, and your system is standard with those limitations.

I'm all in favor of program portability and correctness, but I really don't see a problem here unless one is trying to do something really bizarre to prove a point (such as JET's DUP example).

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================
.

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: LC53 statistics
    ... The '83 standard describes a specific implementation. ... POSTPONE is a replacement for COMPILE and. ... implement state smart words it could come back to bite me on the ass ... look up the word and take only one of the behaviors for later execution. ...
    (comp.lang.forth)
  • Re: LC53 statistics
    ... PygmyForth I had a problem with POSTPONE;. ... If [serves to exit the compiler, allowing the interpreter which called ... But in standard Forth are not supposed to affect the return ...
    (comp.lang.forth)
  • Re: ANS macros.
    ... defined to clarify the writing. ... andif POSTPONE dup POSTPONE if POSTPONE drop; ... M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html ... New standard: http://www.forth200x.org/forth200x.html ...
    (comp.lang.forth)
  • Re: RfD - Enhanced local variable syntax, v4 (long)
    ... to get rid of the immediacy, ... M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html ... New standard: http://www.forth200x.org/forth200x.html ...
    (comp.lang.forth)