,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2021-09-24 11:33:41 ruv wrote: | proposal - Better wording for "Glossary notation" | see: https://forth-standard.org/proposals/better-wording-for-glossary-notation-#contribution-215 `------------------------------------------ ## Author Ruv ## Change Log - 2021-09-24 Initial version ## Problem The section [2.2.4 Glossary notation](https://forth-standard.org/standard/notation#notation:glossary) says: > Each glossary entry specifies a Forth word and consists of two parts: an *index line* and the *semantic description* of the definition. The section [2.2.4.2 Glossary semantic description](https://forth-standard.org/standard/notation#subsubsection.2.2.4.2) says: > The first paragraph of the semantic description contains a stack notation for each stack affected by execution of the word. (underlined by me) The quoted lines are correct for the cases of ordinary words. But for non ordinary words they are incorrect: 1. For non ordinary words the "semantic description" part actually contains a different section for each defined (or explicitly undefined) semantics, with an optional label for semantics and an optional stack diagrams in each section (see [3.4.3 Semantics](https://forth-standard.org/standard/usage#usage:semantics)). 2. The underlined part "by execution" is not correct for non ordinary words (when the section describes a behavior other than execution semantics). Since "execution of a word" means performing its execution semantics. But a section can describe compilation semantics, and the corresponding stack effects can be not equivalent to effects by "execution of the word". Other problems in wording: 3. The underlined part "stack notation" is slightly confusing in its context. In the section [2 Terms, notation, and references](https://forth-standard.org/standard/notation), a notation means a convention. A semantic description in a glossary entry doesn't introduce a new notation, but uses the [stack notation](https://forth-standard.org/standard/notation#subsection.2.2.2) to describe the input and output stack parameters. Such description of the parameters is usually called "stack diagram". 4. Different terms are used to refer a same notion in the quoted lines. Use either "word" or "definition". ## Solution ### Possible solutions per each item #### Item 1 Possible variants - Say that a glossary entry contains the behavior description part that contains one or more *semantic description* sections. - Say that a glossary entry contains one or more *semantic description* parts. The former variant better reflects the idea that semantics describe a behavior in some conditions. But, it seems, the latter variant is simpler without significant losses. Note a label for semantics. Take into account the phrase "When a definition has only one specified behavior, the label is omitted" in [3.4.3.1 Execution semantics](https://forth-standard.org/standard/usage#subsubsection.3.4.3.1). #### Item 2 Use another wording "by performing the semantics" instead of "by execution of the word". #### Item 3 Use the phrase "stack diagram" instead of "stack notation". #### Item 4 Use the normative term "Forth definition". ### Deletions and insertions > Each glossary entry specifies a Forth word definition and consists of two parts: an the index line part and the one ore more *semantic description* parts of for the definition. > The first paragraph of the a semantic description contains an optional label for the semantics and a stack notation stack diagram for each stack affected by execution of the word performing these semantics (if they are defined). ## Proposal ### In the section [2.2.4 Glossary notation](https://forth-standard.org/standard/notation#notation:glossary) Replace the phrase: > Each glossary entry specifies a Forth word and consists of two parts: an *index line* and the *semantic description* of the definition. with the phrase: > Each glossary entry specifies a Forth definition and consists of the *index line* part and one or more *semantic description* parts for the definition. ### In the section [2.2.4.2 Glossary semantic description](https://forth-standard.org/standard/notation#subsubsection.2.2.4.2) Replace the phrase: > The first paragraph of the semantic description contains a stack notation for each stack affected by execution of the word. with the phrase: > The first paragraph of a semantic description contains an optional label for the semantics and a stack diagram for each stack affected by preforming these semantics (if they are defined). ,---------. | Replies | `---------´ ,------------------------------------------ | 2021-09-16 00:20:38 ruv replies: | proposal - Tick and undefined execution semantics | see: https://forth-standard.org/proposals/tick-and-undefined-execution-semantics#reply-776 `------------------------------------------ > The ambiguous condition is generated by _using_ the result, not by ticking the word. Forth-2012 declares that an ambiguous condition exists if a program _ticks_ a word for which interpretation semantics are undefined. Due to this declaration a Forth system is allowed to throw an exception when it encounters (in interpretation state) the phrase `' if`, i.e, when a program even _ticks_ `if`. Also, due to this declaration the phrase `' if` is prohibited for a standard program. And it only means that if a program contains this fragment, then this program is not a standard program. > If systems wish to perform checks in `'` and friends, that is their privilege. > However, the standard should never force a system to do so. And it doesn't force! E.g., the standard doesn't enforce a system what to do if `'` is applied to `if`. It only enforces a standard program in this regard! ----- It seems you want to allow a standard program to tick any available word. But then you have to dictate systems what to do when Tick is applied to `if` (i.e. `' if` or `['] if`) and it will break back compatibility. Perhaps you want to allow a standard program to tick `to` (but not `if`). But it doesn't make any sense, since a standard program cannot use the returned xt, since the corresponding semantics are not specified. ,------------------------------------------ | 2021-09-16 01:02:23 ruv replies: | proposal - Tick and undefined execution semantics - 2 | see: https://forth-standard.org/proposals/tick-and-undefined-execution-semantics-2#reply-777 `------------------------------------------ > Problem [...] > Previous proposals to modify `'` have focused on `'` itself. This proposal focuses on the use of the returned xt. The problem is unclear from this description. Probably, the implied problem is the same as in [my proposal about Tick](https://forth-standard.org/proposals/tick-and-undefined-execution-semantics), namely that applying Tick to some words (e.g. to `s"`) is implicitly ambiguous since the corresponding execution semantics are not specified. > No current system is disenfranchised. It can continue doing what it already does. It's incorrect. Currently, a system may throw an exception when it encounters (in interpretation state) the fragment `' to`, thanks to the declaration of an ambiguous condition when Tick is applied to `to`. After proposed change a system is not allowed to throw an exception in this case (i.e., on `' to`), since this declaration of an ambiguous condition is removed. So, this change is not back compatible. Now a system will be forced to return an xt in this case, but the corresponding execution semantics are not specified anyway. For example, a system is allowed to return just `0`. --- Well, what is a profit of this change? Could anybody provide a use case, a standard program that applies Tick to `to` and does anything useful with the returned value, when the corresponding execution semantics are undefined?