Digest #177 2022-03-19
Contributions
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: <name-of-wordlist>-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
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.
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 {: and for LOCALS| (correspondingly):
Run-time: ( x1 ... xn -- )
Run-time: ( xn ... x2 x1 -- )
Also have a look at 2.2.2 Stack notation: "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 -- )
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.
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.
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.
that
SEARCH-WORDLISTproduces the wid of the wordlistSEARCH
Yes, it can give such an impression on the first glance. With only one correction: FORTH is not a word list, but a vocabulary (a definition that changes the search order, another such a word is 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), 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) 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:), 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.
yes, search can be used as verb - but also as noun.