( -- a-addr )

a-addr is the address of a cell containing the compilation-state flag. STATE is true when in compilation state, false otherwise. The true value in STATE is non-zero, but is otherwise implementation-defined. Only the following standard words alter the value in STATE: : (colon), ; (semicolon), ABORT, QUIT, :NONAME, [ (left-bracket), ] (right-bracket).


A program shall not directly alter the contents of STATE.



Although EVALUATE, LOAD, INCLUDE-FILE and INCLUDED are not listed as words which alter STATE, the text interpreted by any one of these words could include one or more words which explicitly alter STATE. EVALUATE, LOAD, INCLUDE-FILE and INCLUDED do not in themselves alter STATE.

STATE does not nest with text interpreter nesting. For example, the code sequence:

   : FOO S" ]" EVALUATE ;      FOO

will leave the system in compilation state. Similarly, after LOADing a block containing ], the system will be in compilation state.

Note that ] does not affect the parse area and that the only effect that : has on the parse area is to parse a word. This entitles a program to use these words to set the state with known side-effects on the parse area. For example:



Some non-compliant systems have ] invoke a compiler loop in addition to setting STATE. Such a system would inappropriately attempt to compile the second use of NOP.


T{ GT8 -> 0 }T
T{ : GT9 GT8 LITERAL ; -> }T
T{ GT9 0= -> <FALSE> }T


TG9541avatar of TG9541 Advantages of a Forth system with a STATE flag?Request for clarification2021-04-17 07:08:48

I'd like to ask politely for the rationale to mandate an implementation that requires using STATE @ (while forbidding STATE !) instead of just requiring a word that returns the state.

Rationale: eForth uses a pointer ['IDLE] that points to either $COMPILE or $INTERPRET. Testing the state is done by something like : COMPILE? ( -- flag ) 'IDLE @ ['] $COMPILE =.

It's, of course, possible to change the eForth Outer Interpreter but the benefit should outweigh the cost of breaking properties that have a value for small Forth systems (e.g. compactness, extensibility).

ruvavatar of ruv

It's, of course, possible to change the eForth Outer Interpreter

There is another option: just save the corresponding flag into STATE every time when you change 'IDLE. So you can provide STATE word without changing the outer text interpreter.

Also the standard doesn't require a system to use STATE @ for its internal purposes. This method is exposed just for backward compatibility.

instead of just requiring a word that returns the state

Certainly it's a better variant, but even having such a word, the systems are still required to support STATE for some time for backward compatibility.

Meanwhile, I would propose to consider the following names for this word:

COMPILATION ( -- flag )
COMPILING ( -- flag )

TG9541avatar of TG9541

@RUV thanks for your kine reply!

I think I can make a kludge that hides the implementation details - something in the line of "STATE updating a variable when used". Of course that's risky but it has the advantage that it won't create an overhead unless an application uses STATE.

By the way, 'IDLE was a mistake - it should read 'EVAL.

Reply New Version