,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2019-09-04 09:38:20 ruv wrote: | comment - Ambiguous conditions | see: https://forth-standard.org/standard/core/IMMEDIATE#contribution-112 `------------------------------------------ ``` : 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 | `---------´ ,------------------------------------------ | 2019-08-29 08:47:12 ruv replies: | proposal - Clarify FIND | see: https://forth-standard.org/proposals/clarify-find#reply-294 `------------------------------------------ ### 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](https://groups.google.com/forum/message/raw?msg=comp.lang.forth/vrq2f2XXy1Q/0VAbcKOsFQAJ) 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" ,------------------------------------------ | 2019-08-29 09:09:15 ruv replies: | proposal - Clarify FIND | see: https://forth-standard.org/proposals/clarify-find#reply-295 `------------------------------------------ > 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](https://forth-standard.org/standard/core/POSTPONE#contribution-98) 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. ,------------------------------------------ | 2019-09-04 11:08:16 ruv replies: | requestClarification - description of "nt" in the standard | see: https://forth-standard.org/standard/tools#reply-296 `------------------------------------------ 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). ,------------------------------------------ | 2019-09-04 12:23:36 ruv replies: | proposal - find-name | see: https://forth-standard.org/proposals/find-name#reply-297 `------------------------------------------ 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](https://forth-standard.org/standard/core/ACTION-OF) should. Therefore, the result of `search-wordlist`does 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](https://forth-standard.org/standard/core/Tick#contribution-96)). 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. ,------------------------------------------ | 2019-09-04 15:07:43 ruv replies: | proposal - Tighten the specification of SYNONYM (version 1) | see: https://forth-standard.org/proposals/tighten-the-specification-of-synonym-version-1-#reply-298 `------------------------------------------ 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](https://forth-standard.org/standard/core/toBODY). ### 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.