Mon May 25 13:37:42 CEST 2009
While the compiler language tower is ever moving towards a more static
approach, the target interaction language just has become more
The (target: word ...) form is like any other RPN form in Staapl where
the (word ...) represent concatenative code with possible prefix
parser extensions. However, as opposed to other such forms it has
late-bound semantics: identifiers are interpreted at run-time in a
The static name structure of the debugger (as opposed to that of the
program) isn't all that interesting. For debugging, dynamic tweaking
power comes in handy.
Identifiers in the (target: ...) form are tried in several
interpretations successively in the following order until one
1. Prefix parsers from the (target) dictionary like "ul" (upload)
which modify the semantics of subsequent words. Most of these
will expand to scat code that operate on filenames or word names.
2. Compiled words from the (target) dictionary present in the target
code memory. These are simply executed.
3. Macros from the (macro) dictionary. These are compiled to
intermediate code and then interpreted. This doesn't work for
all macros (most notably control words) but provides a convenient
way to perform a computation without having to instantiate macros
as compiled target words.
4. Words residing in the (scat) dictionary are executed.
5. Scheme procedures are dynamically converted to scat semantics and
Doing it this way gives maximum flexibility (all names can be
redefined at run-time in the toplevel namespace) and avoid unnecessary
All the target interaction is defined in live/tethered.ss as a bunch
of scheme functions accessible at all levels. The target console is a
very simple layer on top of this.
One example of how this is quite useful:
tom@zzz:~/staapl/app$ mzscheme picstamp.dict
Connected (/dev/ttyUSB0 230400)
erasing blocks: 22 memory clear.
Press ctrl-D to quit.
> (define (x) (target> ul /tmp/eq.f))