mhx@iae.nl (mhx) writes:
With vocabularies it quickly becomes a pain when,
e.g., defining words in A, switching to B to define
something there, go back to A and define some more
words ... At least it is when trying to FORGET stuff.
(Assuming you *have* FORGET).
That's not particularly hard in the absence of sections: the forgotten
word has an address F, and FORGET just needs to go through all the
words and check if they are above or below F, and eliminate the words
above F from the data structures associated with the dictionary. You
need some way to enumerate all the words; e.g., in a system with a
linked-list implementation of wordlists, you would need a way to
enumerate every wordlist (e.g., the wordlists themselves could also be organized as a lined list), and then walk through each linked list
until the first word below F is found, and make that the new head of
the wordlist. Wordlists that themselves have their data above F also
need to be removed, and in that case also from the search order and
from CURRENT.
With sections, FORGET is a bigger problem, because the forgotten word
resides in one section, and provides only information about what is
newer or older in that section. One way to deal with that is to store
the HERE of every section with every word, but do we really want to go
to these lengths in order to support FORGET? MARKER is a better
interface in the presence of sections.
But even MARKER appears to be much more trouble than it is worth,
mainly because I consider its value to be 0. I have never used it in production code.
It is also messy to write a definition that needs
words from different vocabularies.
( Like a book with footnotes that span multiple pages,
or where a chapter can not be read on its own. )
The search order provides a way to deal with that, especially if the
names in the wordlists don't conflict. Gforth (development) also
includes a scope recognizer, where you write, say, FOO:BAR, and it
uses the word BAR in vocabulary FOO:
vocabulary foo \ ok
also foo definitions previous \ ok
: bar ." bar" ; \ ok
bar
\ *the terminal*:4:1: error: Undefined word
\ >>>bar<<<
\ ...
foo:bar \ bar ok
Still, I usually find it preferable to have everything in the same
wordlist (FORTH-WORDLIST), which makes debugging easier. I did use a
wordlist in my garbage collector library where the internal words of
the library are defined in a separate wordlist that's not in the
search order in applications using that library. The interface words
of the library are defined in the default wordlist (FORTH-WORDLIST
unless you SET-CURRENT differently before loading the library).
I expect that with a very big program like that by CCS one would find
that the balance shifts towards using wordlists/vocabularies more.
- anton
--
M. Anton Ertl
http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs:
http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard:
https://forth-standard.org/
EuroForth 2024:
https://euro.theforth.net
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)