Forth's 2 modes: interpret and compile

Classically, Forth distinguishes two modes:
(I) Interpret mode
(C) Compile mode
Staapl's Forth does the same.
For most languages, this difference is not exposed to the programmer.
Compiled languages usually expose only a single entry point to
compiled code (the "main" procedure), unless they are compiled as
libraries, in which case they are linked to other programs or
libraries and not invoked directly.
Forth however uses the observation that code entry points (program
procedures) behave as individual programs and thus can be executed
individually. This is both convenient and confusing.
Convenient: Interactive use of program components is convenient for
testing. Only exposing the compiled procedures comes
essentially for free: a jump to the code address.
Additionally, this mechanism allows simple implementation
of reflective beaviour. I.e. the subprogram ":"
accessible starts the compilation of new code by switching
to compile mode.
Confusing: Not all language elements that are accessible during
compilation can be accessed in interpret mode. More
specifically, all macros (immediate words) cannot be used.
This includes all structured programmig words like
conditionals and loops.
In order to eliminate this confusion, most compiled languages that
support an interactive console will compile commands given at the
console before executing the freshly compiled code. This makes sure
all language elements are there at the console.
From that perspective, it's probably better to compare Forth's
interactive console to a unix command shell (executing compiled
programs, executing commands to compile new programs) than an
interactive language shell that exposes all language features
available to code to be compiled. In comparison, Haskell's ghci also
do not expose the full language in the repl, i.e. you cannot create
definitions.
In Staapl, interpret mode is not really necessary since the reflection
mechanism of standard Forth that is rooted in this interpret/compile
distinction is not present. It is not that difficult to implement an
extra compile step to make sure console input can use the full
language, not only compiled words, to lessen confusion. In fact a
previous version of Staapl included a ``scratch buffer'' used for
compiling code directly, and I'm planning a simplified language that
uses this as a primary interaction method.
However, the mechanism has been preserved because of the use of Flash
ROM code memory in contemporary microcontrollers with Harvard
architecture. Such memory isn't as easily overwritten as RAM, which
makes generation of temporary code for translation of console commands
difficult. The standard Forth interpret mode allows the execution of
compiled code without touching the Flash memory.
This is extended in Staapl with a simulation layer which can offload
some functionality to the host if it is not present as compiled code.
The reason is that compared to standard Forth, Staapl's Forth is
heavily macro based, and some basic words might always be inlined,
making them not available in interpret mode.