Re: The IMMEDIATE mess

Elizabeth D Rather wrote:
J Thomas wrote:
Andrew Haley wrote:
J Thomas <jethomas5@xxxxxxxxx> wrote:

...

Andrew is doing a fine job with this topic, I just want to add a bit.

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.

Agree entirely. In 35 years I've yet to have a problem with IMMEDIATE.
In fact, I've been at a loss to understand what "mess" it is you're
worried about.

There are two kinds of disadvantages to state-smart words. One kind

...
So I want to find a way to add the features I want instead of get rid
of existing features. Then as the body of code that uses the old
features ages and code that uses the new features builds up, future
standards can consider those old features obsolescent and finally get
rid of them completely.

What I want is increased ability to choose what to do with a word, at
lookup time.

Known methods that can get this include:

[list snipped]

On the other side there's the question whether these capabilities are
worth having. In each case, it could be argued that they give
programmers too much power. If you give Forth programmers power,
they'll use it.

They'll extend the language in new and tricky ways. A standard does
more than code portability, it also provides programmer portability,
and the more tricky code that's hard to understand, the less
interchangeable the programmers.

You're talking about Tom Cruise-type hot-shots who have to show off.
They probably exist in every language, and are mostly anathema to
serious folks just trying to get work done. I object both to adding
features that cater to the hot shots, and equally to efforts to thwart
them that have the side-effect of hampering the ability of the serious
professionals to get their work done.

...

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.

--
Regards
Alex McDonald

.

Relevant Pages

  • 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
    ... 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: 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 program to do either ... line of standard code that has an IMMEDIATE in it. ...
    (comp.lang.forth)
  • Re: Python, Perl, Lua, Ruby -- anybody??
    ... optional 64-bit support. ... There should be a contest to port certain apps to Perl 4 from Perl 5. ... (Yes, it's apparently true, assembly programmers care more about ... couldn't compile for 0.6.2 or so because he only had an x86-64 box ...
    (comp.os.msdos.djgpp)
  • Re: Microsoft and memcpy?
    ... become checked that could not have been checked at compile time. ... the general thinking behind the _s functions is that programmers ... But in the case of memcpy() ... *WILL* change their code in order to leverage this easier syntax which ...
    (comp.lang.c)