ColorForth is actually pretty much an image-based system. Moore observes that PCs have a lot more memory than he needs (indeed 1Mb is huge for a Forth system),

ColorForth is actually pretty much an image-based system. Moore observes that PCs have a lot more memory than he needs (indeed 1Mb is huge for a Forth system), so the image is loaded into memory and the memory is saved to disk. It should be mentioned that Forth is one of those languages that do configuration by editing the source code. This is probably the recommendable practice, instead of INI files or worse, XML (why write another parser when you already have one?). For really big data, binary format would probably be preferred (I actually have no experience in the area), with blocks (as defined in an extension of the ANS Forth standard) acting like Linux' mmap. Strings are a little bit of a pain to deal with in Forth, so you'd rather avoid them where possible (in addition to the consideration that plain text data are inefficient). You'd rather use an hex editor or write visualization and manipulation tools for binary data rather than processing text strings. The fact that Colorforth uses a custom source format to be edited by a custom editor (the colors in the source code is not syntax highlighting, the colors are part of the "syntax") is symptomatic of this kind of approach. A condition/exception system would probably be in the category of "hooks" according to Moore. Stack underflow/overflow are not even an error condition in some of the chips he made that feature circular stacks. However, it is true that for casual Forth programmers like me, a stack underflow condition is usually the result of an error in the program. In a way, just like Haskell programs are "most certainly correct when they compile", Forth programs are most certainly correct if they don't stack-underflow (or just segfault because that's a typical result of messing up the return stack).