,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2020-11-27 07:13:33 ruv wrote: | comment - Data type for strings | see: https://forth-standard.org/standard/usage#contribution-166 `------------------------------------------ [3.1.4.2 Character strings](https://forth-standard.org/standard/usage#subsubsection.3.1.4.2) > A string is specified by a cell pair _(c-addr u)_ representing its starting address and length in characters. [Table 3.1: Data types](https://forth-standard.org/standard/usage#table:datatypes) > _xd_ — unspecified cell pair — 2 cells Don't you think it's convenient to have a symbol for a cell pair _(c-addr u)_ representing a string? For example, _sd_ or just _s_ ? As a result, the stack notation for words that handle strings can be more concise. So, we will have an option to write _( sd1 )_ instead of _( c-addr1 u1 )_. ,---------. | Replies | `---------´ ,------------------------------------------ | 2020-11-14 14:51:43 AntonErtl replies: | referenceImplementation - off-by-one error in reference implementation | see: https://forth-standard.org/standard/search/DEFINITIONS#reply-568 `------------------------------------------ Correct. An alternative implementation: ``` : definitions ( -- ) get-order over set-current set-order ; ``` ,------------------------------------------ | 2020-11-17 09:40:35 AntonErtl replies: | proposal - Recognizer | see: https://forth-standard.org/proposals/recognizer#reply-569 `------------------------------------------ The [Rationale](http://www.forth200x.org/Recognizer-rfc-D-comments.html) for this proposal was split away by Matthias Trute to satisfy complaints about the length of the proposal, but can be useful in understanding the design decisions. ,------------------------------------------ | 2020-11-17 15:48:41 ruv replies: | proposal - Reword the term "execution token" | see: https://forth-standard.org/proposals/reword-the-term-execution-token-#reply-570 `------------------------------------------ > that I think it's inadequate to restrict xt to only refer to execution semantics. I thought about this problem. And I came to the following reasoning. Have a look at the following example: ``` : foo postpone if ; : bar foo ; ' foo ( xt-foo ) ' bar ( xt-bar ) ``` _xt-bar_ identifies the execution semantics for `bar`. But these semantics are equivalent to the execution semantics for `foo`. Then, _xt-bar_ also identifies the execution semantics for `foo`. Then, _xt-foo_ and _xt-bar_ identify the same execution semantics (and they even may be equal, according to [3.1.3.5 Execution tokens](https://forth-standard.org/standard/usage#subsubsection.3.1.3.5)). But the execution semantics for `foo` are equivalent to the __compilation semantics__ for `if`. Then _xt-foo_ __also__ identifies the compilation semantics for `if`. And performing the execution semantics identified by _xt-foo_ is equivalent to performing the compilation semantics for `if`. But you claim that an execution token cannot identify compilation semantics. What is wrong? My conclusion is that any execution token always identifies some execution semantics, and at the same time it identifies any other semantics that are equivalent to these execution semantics. I.e., an execution token cannot identify only some compilation semantics alone, but it identify execution semantics __and__ the compilation semantics that are equivalent to these execution semantics. So we may say that an execution token identifies some compilation semantics (for example), but it shall __imply__ that this execution token also identifies the equivalent execution semantics, and when `execute` is applied to this token, these execution semantics are performed. Ditto for `compile,`. If an _xt_ identifies some interpretation semantics, it just means that it identifies the execution semantics that are equivalent to these interpretation semantics. __Therefore, we don't have any problems on the side of execution token consumers.__ ----- #### Concerning the producers side 1. `NAME>COMPILE` specification doesn't imply that the returned _xt_ identifies something other then some execution semantics. 2. `NAME>INTERPRET` specification can use "__identify__" instead of __represent__: "_xt_ identifies the execution semantics that are equivalent to the interpretation semantics for the word _nt_". But it still doesn't mean that it returns the same value that Tick returns for the same word. 3. Tick (both `'` and `[']`) implies that the returned _xt_ identifies the execution semantics for the word in the argument. My [proposal](https://forth-standard.org/proposals/tick-and-undefined-execution-semantics) fixes some edge cases of using Tick. 4. The term "execution token" is correctly used in `FIND` (at least, it's correct for single-xt systems, and acceptable for dual-nt systems), but single-nt+dual-xt Forth systems don't exactly reflect specification of `FIND`. So, `FIND` should be updated in this regard, since "its execution token _xt_" sometimes is not correct in single-nt+dual-xt systems. --- #### Problem with "executable code" 5. Do we have non executable code? 6. "Executable code" doesn't have any connection with semantics. It looks like a model of a far lower level. 7. Tick returns "the execution token for _name_", that means an identifier of the __execution semantics__ for _name_. So applying `execute` to this _xt_ performs the execution semantics for _name_. After the proposed update, Tick returns an identifier of some "executable code" for _name_. When `execute` is applied to this _xt_, what semantics are performed? It's unclear. ,------------------------------------------ | 2020-11-19 19:58:48 BerndPaysan replies: | proposal - minimalistic core API for recognizers | see: https://forth-standard.org/proposals/minimalistic-core-api-for-recognizers#reply-571 `------------------------------------------ Gforth's new header structure allows to overload `TO`, `IS` (which are essentially the same) and `DEFER@`, so we can use the `DEFER` API to access similar changeable execution patterns implemented differently. So for us, it makes sense to use these access words, regardless how it is implemented. Other systems may not have this capability, though the way the standard now extends `TO` for `FVALUE` and others, you need to have one way or the other to deal with that. Same, when you have an `UDEFER` in your system for user-specific deferred words. For me, it is needless clutter of the dictionary and the mental space of the programmer to add setters and getters for things where you already have a generic one. But I see the point that not every system can do this. ,------------------------------------------ | 2020-11-20 14:25:42 ruv replies: | proposal - minimalistic core API for recognizers | see: https://forth-standard.org/proposals/minimalistic-core-api-for-recognizers#reply-572 `------------------------------------------ > needless clutter of the dictionary and the mental space of the programmer I used an approach when a defined word creates two words — a getter and a setter. It's something like after the phrase `create-prop x` the words `x` and `set-x` are created. I didn't noticed any mental space clutter in this regard. Sometimes I redefined `set-x` to add additional checks or actions. Concerning dictionary space — I don't see any problem. > But I see the point that not every system can do this. True. And even if a system can do this, it's done in some system specific way only. So, due to the combination of all reasons, it's better to have distinct ordinary words in the standard API.