,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2019-10-08 11:01:25 ruv wrote: | proposal - Clarify FIND, more classic approach | see: https://forth-standard.org/proposals/clarify-find-more-classic-approach#contribution-122 `------------------------------------------ It is an alternative proposal to the [one from Anton](https://forth-standard.org/standard/core/FIND#reply-165). ### Problem 1. The existing specification of FIND is unclear how the returned xt is connected with interpretation and compilation semantics for the corresponding word. 2. In some popular Forth systems n=1 does not mean that the word is immediate. ### Solution Use the new wording in the specification for FIND. Keep the original immediacy notion, but use another (more loose) wording for meaning of _n_ in compilation state. The new wording allows to implement the words with undefined execution semantics as "dual-xt" words, and still allows (as it was before) to implement them as immediate STATE-dependent words. Also it allows to have the special definitions to compile the words with undefined interpretation semantics and defined execution semantics (like `EXIT`), and return proper values for them from FIND. No need to mention that FIND may return c-addr 0 for the words with undefined interpretation semantics. It is a consequence of the clause that the returned values depend on STATE, and it is mentioned in the Rationale. Don't change 4.1.2. Perhaps make FIND tighter later when it will be optional. The original specification guarantees that a user-defined text interpreter can interpret all ordinary and user-defined words at least. Now many Forth systems don't use FIND by themselves but provide it for the old-fashion programs only. There is no much sense to restrict the implementation options of the modern Forth systems for the sake of the outdated approach. I think the modern Forth systems will tend to use Recognizer/Resolver approach for the special syntaxes and special words. ### Proposal Replace the text in the specification of FIND with the following. _( c-addr -- c-addr 0 | xt n )_ Find the definition _name_ whose name matches the counted string at _c-addr_. If the definition is not found, return _c-addr_ and zero. Otherwise the definition is found, _xt_ is the execution token for _name_, and _n_ is 1 or -1. The all returned values may differ between interpretation and compilation state. When the definition is found in interpretation state: if the definition is immediate then _n_ is 1, otherwise _n_ is -1; performing _xt_ in intepretation state performs the interpretation semantics for _name_. When the definition is found in compilation state: if _n_ is -1, appending the semantics identified by _xt_ to the current definition performs the compilation semantics for _name_, otherwise performing _xt_ in compilation state performs the compilation semantics for _name_. "Performing _xt_" means performing the execution semantics identified by the execution token _xt_. ----- Please check the [gist at github](https://gist.github.com/ruv/3c75b48f405ecd8842d8024f1dcd0692) for updating and corrections in this proposal. ,---------. | Replies | `---------´ ,------------------------------------------ | 2019-10-08 09:49:20 ruv replies: | proposal - Case sensitivity | see: https://forth-standard.org/proposals/case-sensitivity#reply-339 `------------------------------------------ This approach has the following issue with libraries. A library can use upper-case names just as its own or just an old-fashioned style. And as a Forth system is not obligated to support lower-case access for the non-standard words, a program is compelled to use upper-case access to the words from such library. A possible solution for a standard program is to create the lower-case synonyms automatically for all the new upper-case words after including such library. Perhaps a better approach is to provide for a program a standard ability to explicitly control (turn on or turn off) lower-case access to the new upper-case words (in ASCII charset only).