,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2022-03-18 14:04:40 LSchmidt wrote: | requestClarification - inconsistent naming | see: https://forth-standard.org/standard/search/FORTH-WORDLIST#contribution-229 `------------------------------------------ I'm not really happy with naming `FORTH-WORDLIST` `FORTH-WORDLIST`, for the reason that naming it that way sets the pattern for naming other words which are meant to produce wids according the same pattern: -WORDLIST. Following and applying that pattern would then suggest that `SEARCH-WORDLIST` produces the wid of the wordlist SEARCH, which is clearly not the case. It is therefore my opinion that either `SEARCH-WORDLIST` or `FORTH-WORDLIST` is an inconsistent misnomer, with the name `FORTH-WORDLIST` introducing a resemblance of hungarian notation (making the "type" of the underlying object part of the name). To distinguish `FORTH-WORDLIST` (producing the wid) from `FORTH` (using wid), I think that `FORTHID` or `FORTH-ID` (that it's a wordlist id, I assume user knows, and so the "w" for wordlist doesn't really need to suffer hungarisation) may be a better choice, also in view of naming other words intended to produce wordlist ids. ,---------. | Replies | `---------´ ,------------------------------------------ | 2022-03-09 07:37:08 ruv replies: | requestClarification - Contradiction With do-loops | see: https://forth-standard.org/standard/locals#reply-805 `------------------------------------------ Locals are not accessible for a program if the program has placed data on the return stack. The reason is that in the general case it's unknown at compile-time how many items will be placed on the return stack at run-time. Locals are accessible for a program inside do-loop, since it's known at compile-time how many items will be placed on the return stack by do-loop at run-time, and the system can calculate at compile-time the corresponding offset to access locals. ,------------------------------------------ | 2022-03-09 08:16:15 ruv replies: | requestClarification - Accessing Remaining Data Stack? | see: https://forth-standard.org/standard/locals#reply-806 `------------------------------------------ > No mention is explicitly made about whether or not the remainder of the data stack that was not loaded in to locals would still be accessible during execution of the definition. It's mentioned explicitly via the stack diagrams for run-time semantics for [`{:`](https://forth-standard.org/standard/locals/bColon) and for [`LOCALS|`](https://forth-standard.org/standard/locals/LOCALS) (correspondingly): Run-time: ( x1 ... xn -- ) Run-time: ( xn ... x2 x1 -- ) Also have a look at [2.2.2 Stack notation](https://forth-standard.org/standard/notation#subsection.2.2.2): "Only those stack items required for or provided by execution of the definition are shown". If nothing is shown in the "after" part of a stack diagram, then the parameters are only taken, and nothing is placed on the stack. In the case of the run-time semantics for locals initialization, it efficiently means that a system is not allowed to place a frame of local variables on the data stack. What is missed is the stack diagram for the return stack: `( R: -- locals-sys )` (and the corresponding data type _locals-sys_), since they may place data on the return stack. But then the stack diagrams for the run-time semantics for `exit` and `;` should be updated too: ( R: nest-sys -- | nest-sys locals-sys -- ) ,------------------------------------------ | 2022-03-09 08:35:03 ruv replies: | requestClarification - Accessing Remaining Data Stack? | see: https://forth-standard.org/standard/locals#reply-807 `------------------------------------------ > What is missed is the stack diagram for the return stack: `( R: -- locals-sys )` Probably, a better variant is to rely on _nest-sys_: `( R: nest-sys1 -- nest-sys2 )` Then no need to update the stack diagrams for `exit`, etc. ,------------------------------------------ | 2022-03-11 09:49:00 AntonErtl replies: | requestClarification - Contradiction With do-loops | see: https://forth-standard.org/standard/locals#reply-808 `------------------------------------------ ruv is correct. Another perspective: 13.3.3.2c,d means that a Forth system can store locals on the return stack with few complications; 13.3.3.2g means that if it does that, it has to take DO...LOOP nesting into account when accessing locals (DO..LOOP also can, but is not required to store data on the return stack). By contrast, uses of >R, R> etc. do not have to be statically analysed (and in general, that is not possible, because the program can push a statically non-determinate value on the return stack). The use of a frame pointer would allow accessing locals in the face of statically indeterminate return stack effects, and is used by many (all?) Forth systems that keep locals on the return stack, but the standard authors apparently wanted to allow implementing locals on the return stack without frame pointer and therefore added 13.3.3.2d. ,------------------------------------------ | 2022-03-11 19:15:04 ruv replies: | requestClarification - Contradiction With do-loops | see: https://forth-standard.org/standard/locals#reply-809 `------------------------------------------ For instance, a frame pointer is not used in SP-Forth/4, and local variables are accessed via the return stack pointer. *loop-sys* takes 3 cells on the return stack. I guess, maintain a separate frame pointer is either less efficient (worse run-time performance) or more complex (requires more development/support time) than use of the return stack pointer for that. ,------------------------------------------ | 2022-03-18 18:20:35 ruv replies: | requestClarification - inconsistent naming | see: https://forth-standard.org/standard/search/FORTH-WORDLIST#reply-810 `------------------------------------------ > that `SEARCH-WORDLIST` produces the wid of the wordlist `SEARCH` Yes, it can give such an impression on the first glance. With only one correction: [`FORTH`](https://forth-standard.org/standard/search/FORTH) is not a word list, but a vocabulary (a definition that changes the search order, another such a word is [`ASSEMBLER`](https://forth-standard.org/standard/tools/ASSEMBLER)). In Forth naming culture, a part of speech is very significant. The naming patterns `{verb}-xxx` and `{noun}-xxx` are different. And you cannot expect a similar behavior for the words having names by different patterns. In this case, __search__ is used in names as a verb (see [meaning](https://en.wiktionary.org/wiki/search#Verb)), but __forth__ is used as a noun. And "search-wordlist" means to search **in** the given wordlist, but "forth-wordlist" means just the word list identifier of the "forth". Usually, "verb"-words do something and may have side effects, but "singular-noun"-words don't have side effects (beyond stacks) and just return something. Although, vocabularies (that are nouns) is an exception to the rule due to historical reasons (it's an inconsistency, of course). Many inconsistencies in naming, and even very strange names (like [`>IN`](https://forth-standard.org/standard/core/toIN#contribution-110)) have place just due to historical accidents, since they were introduced when nobody things about consistency, and then they were supported for backward compatibility. But still, some of them were introduced lately (like [`BUFFER:`](https://forth-standard.org/standard/core/BUFFERColon#contribution-69)), unfortunately. As you can see, there are many cases of more significant inconsistencies in naming than this case (that's quite lite). What we can do in this regard in general, is to find better names and introduce them as synonyms, and then, after some long time, obsolete the old names. ,------------------------------------------ | 2022-03-18 19:08:01 LSchmidt replies: | requestClarification - inconsistent naming | see: https://forth-standard.org/standard/search/FORTH-WORDLIST#reply-811 `------------------------------------------ yes, search can be used as verb - but also as noun.