,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2019-07-06 15:45:25 AntonErtl wrote: | proposal - Revise Rationale of Buffer: | see: https://forth-standard.org/proposals/revise-rationale-of-buffer-#contribution-90 `------------------------------------------ ,---------. | Replies | `---------´ ,------------------------------------------ | 2019-07-04 10:45:51 JennyBrien replies: | requestClarification - The case of undefined interpretation semantics | see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-237 `------------------------------------------ 1. cmForth is virtually extinct, and not Standard in many other ways. Perhaps we should stop trying to accommodate it. It seems that with all current Forths, `FIND` will return an xt in interpretation mode whether the definition has interpretation semantics are not. 2. So remove the option that `FIND` may return caddr 0 in interpretation mode for words with no interpretation semantics. If the word is in the search order, `FIND` will return an xt regardless of `STATE`. The implementation of `[DEFINED]` using `FIND` always works as intended. The xt returned is always the execution token except: 1. If the system provides words with dual semantics that may be ticked or POSTPONEd, the xt found while interpreting represents the interpretation semantics and that found while compiling represents the compiling semantics. 2. If the system can mark words as compile-only, a system-defined xt may be returned for such words while interpreting. cmForth's trick was to have a special COMPILER vocabulary where all definitions were immediate and found only at compile time. That's very useful for simple cross-compiling; it ensures that no compiler words are accidentally compiled in the target. But that's a wnole other topic. ,------------------------------------------ | 2019-07-04 10:59:39 JennyBrien replies: | requestClarification - How can the zero result be used in a Standard program? | see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-238 `------------------------------------------ My point is that this would only be useful in a system that has some way to explicitly mark definitions as having no interpretation semantics. ,------------------------------------------ | 2019-07-04 13:04:47 ruv replies: | requestClarification - The case of undefined interpretation semantics | see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-239 `------------------------------------------ To avoid [the flaw](https://forth-standard.org/standard/tools/BracketDEFINED#reply-232) connected with `FIND`, the specification of `[DEFINED]` should not mention `FIND` at all. In such case we will have two (or maybe three) variants: the basic one, the updating by Search-Order word set, and the possible updating by Recognizer word set. I would also suggest to define and use _lexeme_ term (in [2.1](https://forth-standard.org/standard/notation#section.2.1)) to have an easier specification text. The following definitions are a subject for discussion. ### Basic variant Parse a space-delimited lexeme. Return a true flag if the dictionary contains a definition name matching the lexeme; otherwise return a false flag. ### Search-Order word set variant Parse a space-delimited lexeme. Return a true flag if some word list from the search order contains a name matching the lexeme; otherwise return a false flag. ### Recognizer word set variant Parse a space-delimited lexeme. Return a true flag if the lexeme can be recognized by the system's recognizer sequence; otherwise return a false flag. ,------------------------------------------ | 2019-07-04 20:51:22 JennyBrien replies: | requestClarification - The case of undefined interpretation semantics | see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-240 `------------------------------------------ Surely with recognizers youu would check by searching for the name of appropriate the recognizer word? ,------------------------------------------ | 2019-07-05 09:10:58 AntonErtl replies: | comment - What is a standard program | see: https://forth-standard.org/standard/notation#reply-241 `------------------------------------------ "Standard Program" is defined in Section 5.2.1. There have been no problems with it not being in the definition of terms since 1994, so I doubt that including it will help much. ,------------------------------------------ | 2019-07-05 10:18:40 AntonErtl replies: | requestClarification - The case of undefined interpretation semantics | see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-242 `------------------------------------------ IIRC Mark Humphries' system does not find compile-only words when looking for interpreted words, but I don't know if it was published, and reconciling this system with NAME>COMPILE may be a challenge (NAME>INTERPRET should be ok thanks to the possible 0 result). With the current recognizer proposal, if I want to check whether something is recognized, I do ``` s" $-5" forth-recognizer recognize ``` so I don't think that we should let [DEFINED] check recognized things outside the search order. Given that, using the phrase "Parse /name/ delimited by space" is still appropriate. As for having special versions in core and in the search-order wordset, this would spread from FIND to [DEFINED] [UNDEFINED] and FIND-NAME. I think the better approach is to define what "search order" means if there is no search-order wordset. ,------------------------------------------ | 2019-07-05 10:33:38 AntonErtl replies: | requestClarification - How can the zero result be used in a Standard program? | see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-243 `------------------------------------------ The standard defines words with undefined interpretation semantics, and some systems implement this in some way; that's the reason for allowing NAME>INTERPRET to return 0. If you know your system never returns 0 from NAME>INTERPRET, you do not need to write the program in that way, but for portable programs, you have to take this possibility into account. ,------------------------------------------ | 2019-07-05 12:47:36 ruv replies: | comment - What is a standard program | see: https://forth-standard.org/standard/notation#reply-244 `------------------------------------------ I see now, thanks for the reference. I expected to find it it in (2.1) though. It should be noted that (5.2.1) defines Standard Program in large — as end user application. But we used this term just for the fragments of code. More correct use in such case should look like "can this code fragment be a part of a standard program?". It seems too verbose. Perhaps __standard code__ term could be more appropriate. ,------------------------------------------ | 2019-07-05 15:03:21 ruv replies: | requestClarification - The case of undefined interpretation semantics | see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-245 `------------------------------------------ Don't you think that `FIND` should be declared as obsolescent sooner or later? I believe it should. At least due to its counted string argument — in favor of a word that takes `(c-addr u)` pair. From the perspective of `FIND` obsolescence it is better not to spread anything from it. I agree that it is better to define what "search order" means in the specific cases. Also, it is good to define non-parsing factor. For example: `AVAILABLE ( c-addr u -- flag )` --- Regarding the recognizers. I meant [`recognizable?` example](http://amforth.sourceforge.net/pr/Recognizer-rfc-D-comments.html#recognizable) — it is a general method that should be able to also answer whether some word is defined (available) or not. One use case for `[DEFINED]` looks like the following: ``` [defined] foo [if] \ use foo [else] \ workaround [then] ``` With recognizers the following situations can take place. 1\. `foo` is not available via the search order, but it is available via a recognizer (for example, it is a word from SO library). The workaround actually should not be used. 2\. `foo` is available via the search order, but the search order (the system's list of word lists) is not used due to the current recognizer sequence. Using `foo` will produce an error. Therefore I doubt that only the search order should be checked. Actually, recognizers is a part of the search order in general sense. ,------------------------------------------ | 2019-07-06 06:22:51 ruv replies: | requestClarification - The case of undefined interpretation semantics | see: https://forth-standard.org/standard/tools/BracketDEFINED#reply-246 `------------------------------------------ There is no need for special `AVAILABLE` word (as non-parsing factor) if it is limited to the search order, since `FIND-NAME (c-addr u -- nt|0 )` is enough. ,------------------------------------------ | 2019-07-06 15:49:22 AntonErtl replies: | proposal - Revise Rationale of Buffer: | see: https://forth-standard.org/proposals/revise-rationale-of-buffer-#reply-247 `------------------------------------------ Here's a possible text for the revised Rationale: >As a programmer, if your usage complies with the restrictions of >BUFFER: (in particular, no adjacent initialized data that you want to >treat as contiguous with the BUFFER: data), use BUFFER: instead of >CREATE ALLOT, for image size reduction on some systems. > >As a system implementor, you can put the BUFFER: data in uninitialized >memory.