MARKER and BRANCH - September 24th, 2002

You can factor your code at the word level and at the design level. Factoring words is learnt early on by Forth programmers. Most probably also improve this skill over time, with experience. Factoring the design sometimes takes longer to learn.

Flux is designed, much like colorForth, to compile and run small applications on demand, even to the point where parts of the code will not be compiled at all, unless or until they are needed. Code not relevant to the currently executing application is discarded. Thus the system is constantly altering, or existing in a state of flux. :)

However, mayhem can ensue if code is compiled on top of code, on top of code, on top of code. Things become hard to keep track of. Words may be redefined. Crashes occur and bugs lurk. Controlling this dynamic situation can be done conventionally by ensuring that words (both system and application) are not redefined at any stage, or by other methods such as using multiple wordlists. Both of these options introduce complexity. To ensure words are not redefined, odd, non-intutitive names are often resorted to. Wordlists can fix this, but introduce a whole extra wordset and set of rules for controlling the search order and definitions.

It would be useful to have a simple method of ensuring that code gets compiled on top of a known wordlist.

Creating a system BRANCH point from a known MARKER, and then compiling, means code can always reliably be compiled onto a known system state. Once the code in question has completed its execution, the BRANCH can be executed and the system returned to the state it was in, prior to the BRANCH creation. Combine this with MARKERs and dictionary control, roll back, roll forward, erase and define, is easy.