6 Glossary

6.2.1850 MARKER CORE EXT

( "<spaces>name" -- )

Skip leading space delimiters. Parse name delimited by a space. Create a definition for name with the execution semantics defined below.

name Execution:

( -- )

Restore all dictionary allocation and search order pointers to the state they had just prior to the definition of name. Remove the definition of name and all subsequent definitions. Restoration of any structures still existing that could refer to deleted definitions or deallocated data space is not necessarily provided. No other contextual information such as numeric base is affected.

See:

Rationale:

As dictionary implementations have become more elaborate and in some cases have used multiple address spaces, FORGET has become prohibitively difficult or impossible to implement on many Forth systems. MARKER greatly eases the problem by making it possible for the system to remember "landmark information" in advance that specifically marks the spots where the dictionary may at some future time have to be rearranged.

ContributeContributions

JennyBrienavatar of JennyBrien [162] Extending MARKERRequest for clarification2020-09-16 15:33:45

Many years ago, when I was modifying F-83 to be ANS-compilant, I had to temporarily patch several parts of the core. I used:

   CHANGED \  n addr -- ;  add addr and old value to a linked list and then store n at addr

I then modified FORGET to run down the list and restore any values changed after that point.

Is there any common practice on how to add similar further "landmark information" that MARKER should restore?

MarcelHendrixavatar of MarcelHendrix

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.

Reply New Version

ruvavatar of ruv [246] Ambiguous conition for MARKERComment2022-07-16 10:55:40

The glossary entry for forget declares an ambiguous condition:

An ambiguous condition exists if FORGET removes a word required for correct execution.

Probably, a similar ambiguous condition should be declared for the words defined via marker too. Something like the following:

An ambiguous condition exists if definitions or data required for correct execution of the program are removed during execution of name.

Reply New Version

lmravatar of lmr [325] WORDLIST interactionExample2023-12-25 12:05:23

Is MARKER supposed/allowed to also erase subsequent WORDLIST-created wid's? If so, after MARKER deletes a wid, can/must subsequent invocations of WORDLIST re-use that wid (and thereby stay within the system wordlist limit)?

AntonErtlavatar of AntonErtl

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.

lmravatar of lmr

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.

AntonErtlavatar of AntonErtl

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.

Reply New Version