Sujet : Re: single-xt approach in the standard
De : ruvim.pinka (at) *nospam* gmail.com (Ruvim)
Groupes : comp.lang.forthDate : 25. Sep 2024, 08:27:28
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vd0e11$3itr4$1@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla Thunderbird
On 2024-09-23 20:52, Anton Ertl wrote:
Ruvim <ruvim.pinka@gmail.com> writes:
On 2024-09-23 12:36, albert@spenarnc.xs4all.nl wrote:
I also wanted to say that there is an opinion that this definition does
not implement `s"` specified in 11.6.1.2165. An interesting question for
those who share this opinion: how can 11.6.1.2165 be changed (if at all)
to allow this implementation?
The implementation is not in your posting, but I guess you mean a
STATE-smart implementation. One way to allow a STATE-smart
implementation of S" would be to state something like the following in
the "Interpretation:" section of the glossary entry of 11.6.1.2165:
An ambiguous condition exists if the interpretation semantics of S" is
performed in other than interpration state.
Likewise, add the following to the "Compilation:" section:
An ambiguous condition exists if the compilation semantics of S" is
performed in other than compilation state.
So, according to this approach, in the specification for every unordinary word that is allowed to be implemented as a single-xt or as a dual-xt word, you have to mention these ambiguous conditions.
This would be a poor language for specification such words, I think.
It looks like in this approach, you actually partially specify a behavior for xt1 and partially specify a behavior for xt2, and you also specify in which STATE xt1 shall be executed, and in which STATE xt2 shall be executed. One problem in this approach is that you have to repeat the latter for every such word. And another problem is that you still don't specify how to obtain xt1 and xt2.
A better way is to only specify what behavior shall be exhibit when the Forth text interpreter encounters the word in interpretation state (the (observable) interpretation semantics), and what behavior shall be exhibit when the Forth text interpreter encounters the word in compilation state (the (observable) compilation semantics). And in a *common* part specify once how to perform this or that behavior.
For example, we can say:
Performing the execution semantics of a word in interpretation state shall exhibit the (observable) interpretation semantics of the word.
An ambiguous condition exists if execution semantics for a word are not defined by the standard and the system-dependent execution semantics of the word are performed in compilation state.
An ambiguous condition exists if interpretation semantics for a word are not defined by the standard and the system-dependent execution semantics of the word are performed.
Note. The execution semantics of a word are identified by an execution token that can be obtained using `find` in interpretation state, `search-wordlist`, `name>interpret`, `'`, `[']`.
Note. At the moment, if a Forth system provides some standard word and does not provide an execution token of this word, then the system cannot provide the word `forth-wordlist` (due to 16.6.1.1595).
Concerning performing (observable) compilation semantics — this should be specified in `find`, and `name>compile`. In `search-wordlist` we should better specify the meaning of the top output value.
-- Ruvim