6.1.1710 IMMEDIATE CORE

It tuns out that different systems behave differently for your example: Gforth, SwiftForth, and VFX make BAR immediate (i.e., it's the most recently started definition), while iForth makes FOO immediate (i.e., it's the most recently completed definition).

Does it matter? I do not see a good reason for starting another definition, then making the previous definition immediate. I can see a case for making the most recently started definition immediate in metaprogramming, e.g.,:

: macro: : immediate ;

However, I am not aware that anybody has ever written such code (but as usual, absence of evidence is not evidence of absence).

Does it matter? I do not see a good reason for starting another definition, then making the previous definition immediate. I can see a case for making the most recently started >definition immediate in metaprogramming, e.g.,:

: macro: : immediate ;

However, I am not aware that anybody has ever written such code (but as usual, absence of evidence is not evidence of absence).

I used to do that very thing many years ago, on the basis of 'say what you are doing as soon as you can'. It's a nice thing to have, and I'm not sure why iForth doesn't allow it. (a combination of expecting LATEST to be the top of the CURRENT wordlist, and only linking it there with ; ?)

Answer for the TC:

: creates a new definition. Therefore, in the example above, bar is the most recent definition, and should be affected by immediate. This is not ambiguous.

The standard allows the implementations where IMMEDIATE affects the last definition in the compilation word list. It is the only reason for the following ambiguous condition (from 16.3.3):

An ambiguous condition exists if a program changes the compilation word list [...] before modification of the behavior of the most recently compiled definition with [...] IMMEDIATE

Also the following ambiguous condition (also from 16.3.3) allows to place the current definition name into the compilation word list only on Semicolon:

An ambiguous condition exists if a program changes the compilation word list during the compilation of a definition

Actually, having TRAVERSE-WORDLIST, a colon-definition name should be placed into the compilation word list only on Semicolon (and not before). Otherwise it would be strange that some name can be unfindable via SEARCH-WORDLIST but available via TRAVERSE-WORDLIST.

Therefore, I think it is an ambiguous condition in the example above.

The committee discussed and voted on whether to remove this ambiguous condition. The result of the vote was 6Y/4N/2A, which is not enough for a consensus, so the ambiguous condition is not being removed. The TRAVERSE-WORDLIST issue has been discussed and decided separately.

The standard allows the implementations where IMMEDIATE affects the last definition in the compilation word list. It is the only reason for the following ambiguous condition (from 16.3.3):

An ambiguous condition exists if a program changes the compilation word list [...] before modification of the behavior of the most recently compiled definition with [...] IMMEDIATE

It turns out that this sentence also covers the case of:

MARKER m
: foo 1 ;
m
IMMEDIATE

since the execution of m changes dictionary pointers. In the process of forgetting both m and foo, it is also making it impossible to portably determine whether there is a most-recent compilation that immediate can affect. But it would be nice to state that directly in the text for IMMEDIATE and/or MARKER, rather than having to refer to the Search word set to find that out.

Is it ambiguous if immediate is performed more than once on the same definition, or is this an appropriate testsuite addition:

T{ 0 VALUE x -> }T
T{ : a 1 TO x ; IMMEDIATE IMMEDIATE -> }T
T{ x : b a ; x 2 TO x b x -> 0 1 2 }T

There is an observable difference if an implementation implements immediate by toggling a bit, where toggling it twice reverts to non-immediate; compared to an implementation that only ever sets the bit (even if it is already set). From my testing, at least gforth and SwiftForth treat the second immediate as a nop; but since at least Jonesforth (yes, I know that's not a standard implementation) treats it as a toggle, I'm wondering if there any standard implementations that toggle.

The wording of the specification seems clear to me. Toggling does not implement this specification.

since the execution of m changes dictionary pointers.

Yes, formally, "change the compilation word list" can cover both cases:

1. make another word list the compilation word list;
2. change the state of the compilation word list (i.e., add or remove words in the word list).

But adding a word does not lead to an ambiguous condition, because the added word becomes "the most recently compiled definition". Hence, the entire case (2) does not apply.

It seems intuitively obvious which word is "the most recently compiled definition" in the dictionary after execution of a marker — it is the word that had this status just before the marker was defined (but only if execution of a marker restores the search order and the compilation word list in use). I don't see a technical problem in implementing this.

Thus, the same as for does> (see my reply-1501), we should either formally declare an ambiguous condition concerning execution of markers, or treat the intuitive understanding which word is "the most recently compiled definition" as implied by the standard (and clarify this).

A double IMMEDIATE is already tested in the test suite file coreplustest.fth