IMMEDIATE

( -- )

Make the most recent definition an immediate word. An ambiguous condition exists if the most recent definition does not have a name or if it was defined as a SYNONYM.

See:

Rationale:

Typical use: : X ... ; IMMEDIATE

Testing:

T{ 123 CONSTANT iw1 IMMEDIATE iw1 -> 123 }T
T{ : iw2 iw1 LITERAL ; iw2 -> 123 }T

T{ VARIABLE iw3 IMMEDIATE 234 iw3 ! iw3 @ -> 234 }T
T{ : iw4 iw3 [ @ ] LITERAL ; iw4 -> 234 }T

T{ :NONAME [ 345 ] iw3 [ ! ] ; DROP iw3 @ -> 345 }T
T{ CREATE iw5 456 , IMMEDIATE -> }T
T{ :NONAME iw5 [ @ iw3 ! ] ; DROP iw3 @ -> 456 }T

T{ : iw6 CREATE , IMMEDIATE DOES> @ 1+ ; -> }T
T{ 111 iw6 iw7 iw7 -> 112 }T
T{ : iw8 iw7 LITERAL 1+ ; iw8 -> 113 }T

T{ : iw9 CREATE , DOES> @ 2 + IMMEDIATE ; -> }T
: find-iw BL WORD FIND NIP ;
T{ 222 iw9 iw10 find-iw iw10 -> -1 }T    \ iw10 is not immediate
T{ iw10 find-iw iw10 -> 224 1 }T          \ iw10 becomes immediate

See F.6.1.2510 ['], F.6.1.2033 POSTPONE, F.6.1.2250 STATE, F.6.1.2165 S".

ContributeContributions

ruvavatar of ruv Ambiguous conditionsComment2019-09-04 09:38:20

: foo ." foo " ;
: bar [ immediate ] ." bar " ;

What definition should be affected by this call of immediatefoo or bar ?

It seems it is not specified clear enough and in the different Forth systems the result may be different. Therefore, this situation should be declared as an ambiguous condition at the moment.

Actually, the result depends on interpretation of the "most recent definition" expression. I could say it is a definition that was completed (i.e. compilation ended) most recently.

Perhaps this term should be accurately defined in the future.

AntonErtlavatar of AntonErtl

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).

JennyBrienavatar of JennyBrien

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 ; ?)

BerndPaysanavatar of BerndPaysan

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.

ruvavatar of ruv

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.

AntonErtlavatar of AntonErtl

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.

Closed
Reply New Version