6.2.1850 MARKER CORE EXT

As iForth supports FORGET and making executables, it has lots of support for saving 'structural' details of which MARKER is just one example. Of the top of my head: Each word has a FORGET and REVISION fields, and each word has the option of defining a FORGET> section with code that is executed when it is forgotten (like the DOES> construct). Words can be hooked into several lists ( chains ) that are walked through when certain events occur (like COLD). Included files can be marked as a revision that is automatically unhooked when the file is reloaded. When Forth is used as an application shell and is allowed to compile, one frequently wants to clean up the dictionary when the user wants to work on another file.

A wordlist may be dynamically allocated in data space, which means it can come from the dictionary space mentioned by marker (this terminological inconsistency should be fixed). And the wid may be the address of that location, so marker is allowed to delete wids and programs cannot rely on their continued existence. Is marker guaranteed to do that? I find no trace of such a guarantee in the specification (but of course that would require the specification of marker to be updated in the chapter on the search-order wordset).

Consequently, if marker deletes wids, subsequent invocations of wordlist may or may not reuse deleted wids.

Overall, my take on marker is that it is a programmer convenience for those cases where exiting the session and restarting is from the beginning (what I usually do) is too inconvenient. Apart from the minimum guarantees required by the standard, implement as little functionality as you want without unduly inconveniencing your users and as much as you can without unnecessarily complicating your system. Or maybe don't implement marker at all.

Thanks, that makes sense. I guess I had in mind a simple "increasing counter" implementation of wid's. I'll restate the question as: once a wid is freed up by MARKER, can it still count towards the (8, or whatever) WORDLIST limit the system imposes? Or must the system only limit "active" wid's (if at all)?

For example, a system implementing u8int wid's (as an index into a fixed vector) would be forced, in the latter case, to reuse wid's after at most 255 paired WORDLIST / MARKER invocations. If the system is allowed to not reuse wid's, OTOH, then it can declare overflow after 255 such invocations, since it would run out of "fresh" wid's.

As mentioned, there is no guarantee, so a system could run out of wordlists after 8 calls to WORDLIST, whether there were markers used or not.

However, if you use a counter for generating wids, its straightforward to implement marker such that it saves the counter in the generated marker and that the marker restores the counter.