,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2020-09-02 11:16:03 StephenPelc wrote: | proposal - Call for Vote - Ambiguous condition in 16.3.3 | see: https://forth-standard.org/proposals/call-for-vote-ambiguous-condition-in-16-3-3#contribution-155 `------------------------------------------ ## Stephen Pelc # Call for Vote Remove the ambiguous condition in 16.3.3
An ambiguous condition exists if a program changes the compilation word list during the compilation of a definition or before modification of the behavior of the most recently compiled definition with ;CODE, DOES>, or IMMEDIATE.
The ambiguous condition permits systems to use the CURRENT wordlist to find the most recent name. Given the variety and complexity of recent wordlist structures, this apparent simplicity is rarely found compared to just updating a pointer for each name. ,------------------------------------------ | 2020-09-02 20:57:52 StephenPelc wrote: | proposal - Interpretation semantic for locals are undefined | see: https://forth-standard.org/proposals/interpretation-semantic-for-locals-are-undefined#contribution-156 `------------------------------------------ Stephen Pelc, 2 Sept 2020 See https://forth-standard.org/proposals/wording-declare-undefined-interpretation-semantics-for-locals#contribution-133
RUV states that interpretation semantics for locals are undefined. This is true for (LOCAL) so we should add:
local Interpretation:
Interpretation semantics for this word are undefined. LOCALS| refers to (LOCAL) so (LOCAL) covers the case. For {: we need to add:
name Interpretation
The interpretation semantics of name are undefined
then remove the ambiguous condition in name Execution. ,---------. | Replies | `---------´ ,------------------------------------------ | 2020-09-02 05:59:27 AntonErtl replies: | proposal - XML Forth Standard - migration from LaTeX to DocBook | see: https://forth-standard.org/proposals/xml-forth-standard-migration-from-latex-to-docbook#reply-456 `------------------------------------------ > How do you like the XML definition for words? I like the tags used, very fitting for the task. What I am wondering about: If something new comes up, like the "TO name semantics" in Forth-2012, how easy is it to add that? What I don't like are general problems of XML: extreme verbosity, and the need to escape > and < (probably also &); this is especially noticable in the testing section of the example. But you are the editor, so it's your decision, and if the next editor wants something better, the XML format allows automatic conversion to the next format (but it should also happen if the reverse direction is also possible, i.e., no information is lost). > Would your system/documentation also output this XML definitions for its own words? Probably possible, but for now I don't see a benefit. > Any other related feedback? How does this format cope with showing changes? ,------------------------------------------ | 2020-09-02 07:24:19 AntonErtl replies: | proposal - Remove the “rules of FIND” | see: https://forth-standard.org/proposals/remove-the-rules-of-find-#reply-457 `------------------------------------------ SEARCH-WORDLIST is specified as "Find ... in the word list identified by wid". So "find" in 16.2 may be better defined as: > **find:** > To search the search order or a wordlist for a definition name matching a given string. or > **find:** > To search (without qualification) the search order or (when a wordlist is mentioned) the wordlist for a definition name matching a given string. ,------------------------------------------ | 2020-09-02 07:44:20 AntonErtl replies: | proposal - Traverse-wordlist does not find unnamed/unfinished definitions | see: https://forth-standard.org/proposals/traverse-wordlist-does-not-find-unnamed-unfinished-definitions#reply-458 `------------------------------------------ ## Author: M. Anton Ertl ## Change Log: Initial version ## Problem: [Does TRAVERSE-WORDLIST find unfinished or nameless definitions](https://forth-standard.org/standard/tools/TRAVERSE-WORDLIST#contribution-118)? ## Solution: It does not. ## Proposal: Change > Execute xt once for every word in the wordlist wid, into > Execute xt once for every named word that can be found in the word list wid, Insert, before "TRAVERSE-WORDLIST may visit ..." > A word that used to be findable in the wordlist but no longer is (because another word with the same name has been defined in the wordlist) may or may not be returned by TRAVERSE-WORDLIST. ## Discussion This is a wording change. The insterted sentence allows shadowed entries to be visited and reflects the sentence "Whether duplicated nodes are visited or not by TRAVERSE-WORDLIST is undefined." in the [original proposal](http://www.forth200x.org/traverse-wordlist.html). ,------------------------------------------ | 2020-09-02 09:40:34 BerndPaysan replies: | proposal - Remove the “rules of FIND” | see: https://forth-standard.org/proposals/remove-the-rules-of-find-#reply-459 `------------------------------------------ Replace the text > Return a true flag if *name* is the name of a word that can be found (according to the rules in the system's FIND); otherwise return a false flag. with > Try to find *name.* Return a true flag if *name* can be found; otherwise return a false flag. Add the following redefinition of the term “find” to 16.2: > **find:** > To search the search order or a specified wordlist for a definition name matching a given string. Cross-reference 2.1 find and 16.2 find. ,------------------------------------------ | 2020-09-02 11:17:55 StephenPelc replies: | proposal - Call for Vote - Ambiguous condition in 16.3.3 | see: https://forth-standard.org/proposals/call-for-vote-ambiguous-condition-in-16-3-3#reply-460 `------------------------------------------ ## Stephen Pelc # Call for Vote Remove the ambiguous condition in 16.3.3
An ambiguous condition exists if a program changes the compilation word list during the compilation of a definition or before modification of the behavior of the most recently compiled definition with **;CODE**, **DOES>**, or **IMMEDIATE**.
The ambiguous condition permits systems to use the CURRENT wordlist to find the most recent name. Given the variety and complexity of recent wordlist structures, this apparent simplicity is rarely found compared to just updating a pointer for each name. ,------------------------------------------ | 2020-09-02 11:56:44 ruv replies: | proposal - Traverse-wordlist does not find unnamed/unfinished definitions | see: https://forth-standard.org/proposals/traverse-wordlist-does-not-find-unnamed-unfinished-definitions#reply-461 `------------------------------------------ What is a rationale to allow `TRAVERSE-WORDLIST` to miss nt for a shadowed word? In any case, a Forth system cannot reuse the same nt for the different definition (i.e., that has the different behavior), since this nt (literally) could be already compiled by a program. Also, for better [reflection](https://en.wikipedia.org/wiki/Reflection_(programming)), `TRAVERSE-WORDLIST` should return nt for every word that was placed into a word list (and that wasn't excluded as the result of a word created by [MARKER](/standard/core/MARKER)). IIRC, years ago a kind of recognizer was suggested by Michael Gassanenko to access the shadowed words. ,------------------------------------------ | 2020-09-02 12:15:59 AntonErtl replies: | proposal - Traverse-wordlist does not find unnamed/unfinished definitions | see: https://forth-standard.org/proposals/traverse-wordlist-does-not-find-unnamed-unfinished-definitions#reply-462 `------------------------------------------ The idea was that some system might have a hash table that contains each name only once (i.e., the latest definition). Of course, a system that implements MARKER or FORGET would not go there. There probably are no such systems, so if somebody proposes to eliminate this option, there may be little resistance, but I am reluctant to do this in this proposal, which is intended to just be a wording change. ,------------------------------------------ | 2020-09-02 12:19:35 ruv replies: | proposal - Call for Vote - Ambiguous condition in 16.3.3 | see: https://forth-standard.org/proposals/call-for-vote-ambiguous-condition-in-16-3-3#reply-463 `------------------------------------------ A Forth system may use the different memory sections for the different word lists (for example, it may use the different section for the system's and for user-defined word lists). This approach is used in SP-Forth. Changing the compilation word list causes changing the current section. So changing the compilation word list during compilation will produce incorrect code. If we remove the mentioned ambiguous condition, we destandardize such Forth systems and prohibit such approach in implementations. Also, by this changing, we, without any profit, destandardize and prohibit the approach when nt is actually created by semicolon `;` (I uses this approach). Concerning using `CURRENT` to find the most recent name — this approach is used in my system. It seems for me that complexity of wordlist structures is an argument that it can have one more cell to keep the reference to its most recent nt. ,------------------------------------------ | 2020-09-02 13:10:42 UlrichHoffmann replies: | proposal - Nestable Recognizer Sequences | see: https://forth-standard.org/proposals/nestable-recognizer-sequences#reply-464 `------------------------------------------ Some remarks: - Is it a good idea to have defining words such as rec-sequence and id-creating words such as wordlst both in the standard? Seems to be inconsistent to me. - Isn't the Forth way to chain execution tokens to put them in colon definitions? Why do we need req-sequence? ,------------------------------------------ | 2020-09-02 13:55:59 BerndPaysan replies: | proposal - Remove the “rules of FIND” | see: https://forth-standard.org/proposals/remove-the-rules-of-find-#reply-465 `------------------------------------------ Replace the text in [DEFINED] > Return a true flag if *name* is the name of a word that can be found (according to the rules in the system's FIND); otherwise return a false flag. with > Try to find *name.* Return a true flag if *name* can be found; otherwise return a false flag. Add the following redefinition of the term “find” to 16.2: > **find:** > To search the search order or a specified wordlist for a definition name matching a given string. Cross-reference 2.1 find and 16.2 find. ,------------------------------------------ | 2020-09-02 15:28:08 GeraldWodni replies: | requestClarification - Why RECURSE is needed? | see: https://forth-standard.org/standard/core/RECURSE#reply-466 `------------------------------------------ This his been discussed by the TC and we deem the replies above by Anton Ertl and Peter Knaggs to clarify the question. As to smudging: this is not used in the standard any more. ,------------------------------------------ | 2020-09-02 15:31:15 GeraldWodni replies: | referenceImplementation - sample implementation that can also be interpreted | see: https://forth-standard.org/standard/core/WITHIN#reply-467 `------------------------------------------ The TC agrees that ruv's response is correct. ,------------------------------------------ | 2020-09-02 21:10:07 StephenPelc replies: | requestClarification - Word set of S>D word | see: https://forth-standard.org/standard/core/StoD#reply-468 `------------------------------------------ The Technical committee has considered your submission.
The number conversion words **<# # #S #>** and friends require double numbers.
In order to use these words to display both single and double numbers **S>D** is required. Therefore we leave **S>D** in the **CORE** word set.