Digest #79 2019-09-05
Contributions
: foo ." foo " ;
: bar [ immediate ] ." bar " ;
What definition should be affected by this call of immediate — foo 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.
Replies
1. Immediacy notion.
It also uses a different notion of immediacy from the one in the Definition of Terms.
I believe this is an inconsistency. But in the message news:2019Aug2.082728@mips.complang.tuwien.ac.at you wrote:
I don't think there is an inconsistency in the normative text of the standard here. It's just that the normative text does not reflect the intention of the Forth-94/2012 committees.
Using immediacy in different notion is an inconsistency regardless of the intention. But if you changed your mind the wording in the proposal perhaps should be updated accordingly.
Another possible interpretation is following. If we suppose that when FIND returns different xt depending on STATE it returns xt for the different Forth definitions, then each of them can be independently immediate (or not immediate) in the notion from the Definition of Terms. This idea also conforms to the conception that a Forth definition can have not more than one execution semantics. Also, in cmForth and Mark Humphries' system they are actually the different Forth definitions (the words from the different word lists having the same name, or the words having the same name but the different flags).
2. An ambiguous condition on obtain the execution token
It seems that removing "6.1.1550 FIND" is not enough, since the statement mentions just some examples due to using "e.g." and "etc.". It is need to enumerate exactly all the possible variants.
OTOH, in the proposed specification FIND does not return execution tokens for the corresponding Forth definition (in the general case). It returns (on success) the pair of values that represents the compilation semantics or the interpretation semantics (the latter is expressed less clear although), or something else. But from the returned values we can say nothing about execution semantics (according to the proposed specification).
3. Performing the returned xt in the different STATE
The cases of ambiguous POSTPONE can be eliminated in the future, but it will not affect the limitation on performing the corresponding tokens in the same state only. Also this limitation should be applied for some other words too (e.g. for words with undefined interpretation semantics, since these words may be implemented as "state-smart").
So, it is better to refer them via undefined (or unspecified) execution semantics.
E.g.: "If the definition is for a word for which execution semantics is not specified by the Standard, it is ambiguous to perform the xt returned by FIND in a STATE different from the STATE during FIND"
Another issue is that in this case the returned values do not represent the compilation semantics (since we don't know from these values should we set compilation state to perform these semantics or not), but the text says that "In compilation state, the returned values represent the compilation semantics"
4. Implementing some words via recognizer
It seems that the current specifications wording allows to implement the words with undefined interpretation (or even execution) semantics via the recognizer mechanism, and they may be unfindeable by FIND in such case. But the proposed specification excludes such implementation approach. Could it be changed to don't exclude this approach?
The idea: If the definition has no execution semantics, FIND may produce c-addr 0;
5. Terminology
Why is the "represent" term used instead of the "identify" term?
E.g. "the returned pair of values identifies the compilation semantics".
Have a look to the following normative text from the current Standard: "execution token: A value that identifies the execution semantics of a definition"
Note that this does not allow STATE-smart implementations of words without interpretation semantics (e.g., IF), but then, that's already forbidden by POSTPONE and [COMPILE].
It is wrong that it's already forbidden. POSTPONE (and [COMPILE]) does not forbid STATE-smart implementations of the words with undefined interpretation semantics (like IF). I suggested a simple implementation of POSTPONE that supports STATE-smartness for these words (like IF or ACTION-OF, etc.).
Therefore, the updated specification should allow the STATE-smart implementations for the words with undefined execution semantics.
I think, "named word" is a tautology, since formally there no such thing as "not named word"; the only definition (a Forth definition) is what can be named or not named (i.e.: named definition, not named definition).
Have a look at the following definitions:
defining word: A Forth word that creates a new definition when executed.
standard word: A named Forth procedure, formally specified in this standard.
definition: A Forth execution procedure compiled into the dictionary.
word set: A set of Forth definitions grouped together in this standard under a name indicating some shared aspect, typically their common functional area.
Therefore =>
standard word: A named definition, formally specified in this standard.
Therefore =>
word: A named definition.
And the "word" term is often used in this sense (and in the standard too), but this sense is missed in the definition for the word term:
word: Depending on context, either 1) the name of a Forth definition; or 2) a parsed sequence of non-space characters, which could be the name of a Forth definition.
E.g.: "A word that returns an ior ", "defining word" — "word" here is neither (1) nor (2).
Regarding the critiques of SEARCH-WORDLIST
1. It produces results with a varying number of stack items. In some situations that makes it more cumbersome to use.
It is a weak argument, since in other situations that makes it less cumbersome to use. Sometimes I would even prefer ( xt immediate-flag true ), where imediate-flag is -1 for immediate and 0 otherwise.
2. Its interface is designed for single-xt+immediate-flag systems,
Strong argument. Actually it means that the dual-semantics words that are not implemented as immediate cannot be represented as a result of this word.
An example. In Gforth "action-of" forth-wordlist search-wordlist says that the returned xt is for a word whose compilation semantics is to perform the given execution semantics (in the compilation state, by my inference). But performing this compilation semantics does not produce the result that standard ACTION-OF should. Therefore, the result of search-wordlistdoes not represent the standard action-of word, but something else.
It is either incorrect result or an implicit ambiguous condition (the same as for Tick). Whatever the truth, I would say that more correct is to return 0 in this case.
3. In the general case, given that the xt part of the result does not represent a part of the compilation semantics, the 1/-1 part of the result is pointless.
In a Forth system that implements dual-semantics words as a state-smart, the result (xt code pair) properly represents the compilation semantics (as well as interpretation semantics) in the general case.
In any standard Forth system 1/-1 part of the result is not pointless for standard or user-defined immediate words.
Some comments.
1. Reference implementation
The current reference implementation is not correct for the new specification, therefore it should be updated or removed.
2. Execution semantics
The same execution semantics should be also mentioned. Otherwise, ticking a synonym is implicitly ambiguous.
3. Synonym of a defining word
It seems, the proposed specification does not take into account the case of a synonym of a defining word, but perhaps it should.
E.g. "defined via CREATE or the synonym of such a word" — i.e. the synonym of a word that was defined via CREATE. But what about the following:
SYNONYM C CREATE
C X 0 ,
Is X defined via CREATE? It is not clear.
OTOH, in the case like : C CREATE ; C X 0 , it is clear that X is defined via CREATE, and therefore >BODY is applicable for the corresponding xt.
Nevertheless, for DOES> the specification says: "if name was not defined with CREATE or a user-defined word that calls CREATE". I wonder why does not it say the same for >BODY.
4. Terminology
The fragment "DOES> is applied to newname" looks not quite correctly. I think it should look like "DOES> run-time semantics is performed when newname is the most recent definition".
But this statement is not needed at all since this ambiguous condition already exists due to: "An ambiguous condition exists if name was not defined with CREATE or a user-defined word that calls CREATE".
5. Absent issue
At least one issue that is mention in "Problem" section (in items 2, 3) is actually absent: the current specification guarantees that a synonym contains the same value, and a synonym always produces the same result as the original word, due to the same interpretation and compilation semantics.