Digest #142 2021-04-18
Contributions
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.
requestClarification - Advantages of a Forth system with a STATE flag?
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).
Replies
comment - Note incompatability (double v single) with some older Forth's.
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 int and long int with respect to the native word width in the C language).
requestClarification - Advantages of a Forth system with a STATE flag?
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 )
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, 13.6.1.2295 TO.
requestClarification - Does the standard assume that DEFER was created with CREATE?
I've seen the part about examples being non-normative. I'm closing this now. Thanks for your work!
requestClarification - Advantages of a Forth system with a STATE flag?
@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.