Re: The IMMEDIATE mess

J Thomas wrote:
I don't have a proposal thought out, only some beginning ideas. Anybody
is welcome to build on them for whatever purpose, or to criticise them.

Usually what we need is not IMMEDIATE words or state-smart words.
IMMEDIATE was a quick simple hack that people have been working around
for 30 years. It's usually adequate, but not good.

Any word that includes POSTPONE or executes COMPILE, (or [COMPILE] ?)
is compile-only, and recursively any word that executes a word that
includes POSTPONE etc it compile-only.

The complications of state-smart etc don't belong in the words
themselves. The issue doesn't come up after you execute the words. The
issue comes up in the interpreter/compiler, when you FIND words and
decide what to do with them.

What if FIND (or its string-and-count replacement) were to give more
information? What if it were to give

-3 normal compilation behavior, do not interpret.
-2 discard the xt always, do nothing.
-1 execute when interpreting, compile when compiling.
0 not found
1 immediate
2 do not interpret, execute while compiling
3. execute while compiling, do not execute while interpreting, but a
second xt is available to execute while interpreting or fetch with '
['] etc. The other xt can be found with a special command.

Wouldn't a lot of the endless complications go away if this extra
information was available to standard programs?

Whenever you POSTPONE a word or compile COMPILE, the current word
becomes type -3 unless it already has compiled : or :NONAME or
postponed DOES> , and if you try to make it immediate it becomes type
2. The rules for that might turn out to be too complicated to use, but
some of them might give useful warning messages without getting too
much in the way.

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. An improved FIND and more sophisticated behaviors at
that point might do it.


I have nothing against a FIND that supplies more information, but
I fail to see why IMMEDIATE causes a mess. If you get rid of
IMMEDIATE how is ; going to work? Not to mention IF ELSE THEN BEGIN
WHILE UNTIL etc.

I am not sure that defining a DUP that tells you how often it
is compiled or executed justifies the proposed changes---after
all, you can always sort a program by words and count the
instances of any word.

--
Julian V. Noble
Professor Emeritus of Physics
University of Virginia
.

Relevant Pages

  • Re: FORTH: BEGIN as compile-time and no run-time?!?!?!?!? Help
    ... BEGIN is executed at compile time to push on the stack an address ... > IMMEDIATE identifies words to be executed at compile time. ... > cases will either execute it or compile some reference to it depending on a ...
    (comp.lang.asm.x86)
  • Re: FORTH: BEGIN as compile-time and no run-time?!?!?!?!? Help
    ... BEGIN is executed at compile time to push on the stack an address ... IMMEDIATE identifies words to be executed at compile time. ... but they still must execute IMMEDIATE words instead of ...
    (comp.lang.asm.x86)
  • 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
    ... 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: How do you do this?
    ... SwiftForth, VFX, gForth, bigForth, iForth, tforth, win32Forth, ... ANS Forth is too powerful to execute from an untrusted source without ... So one could also compile the code with optimization ...
    (comp.lang.forth)