Digest #142 2021-04-18
The word interpretation and compilation semantic of the word is defined but I fail to understand the context of its usage without, at least, an example. In order to use or implement
TO but as a human I first have to understand the intent, purpose or meaning of the word in the context of Forth.
Rationale: in the English language the word
to has many idiomatic uses - coming from a Forth-79 background its purpose, meaning or intent isn't obvious and no reference to the documentation of modern implementation is offered.
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
$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).
As a maintainer of an old 8bit STC eForth variant I'm taking note of this discussion, and I'm of course thinking about options as using 32 bit math on a 8 or 16bit system is expensive. Before I take a decision, I'd like to clarify what "double" means on the background of the discussion "
S>D in the standard, not double word set". I'd like to know what a double is in a system with 32 cells ( I'm reminded of the ambiguities of
long int with respect to the native word width in the C language).
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
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 )
I was pointed to the win32forth doc which contains the following description:
TO CORE EXT
Interpretation: ( x "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Store x in name. An ambiguous condition exists if name was not defined by VALUE.
Compilation: ( "<spaces>name" -- )
Skip leading spaces and parse name delimited by a space. Append the run-time semantics given below to the current definition. An ambiguous condition exists if name was not defined by VALUE.
Run-time: ( x -- )
Store x in name.
Note: An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO.
See: 6.2.2405 VALUE, 126.96.36.1995 TO.
I've seen the part about examples being non-normative. I'm closing this now. Thanks for your work!
@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
By the way,
'IDLE was a mistake - it should read