Partial evaluation.

I'm not really sure yet what this is about. It's a pattern I ran into
while writing the peephole optimizer. And, no doubt, this is a special
case of something more general. But it's remarkable nonetheless..

I start with something concluded elsewhere: due to lack of named
parameters, the annotation present in naming needs to happen somewhere
else. (I'm assuming that annotation is essential to human
understanding of a program.) For a compositional program this is
trivial: identify substeps, and name them.

So. I set out to properly factor my macros. Some Forth macros, like
FOR .. NEXT, come in pairs, and need to maintain some kind of state
during the code generation process. They are basicly just scheme
parentheses, so require a 'parsing stack'. This is the CAT data
stack. These macros don't need a lot of access to the compilation
buffer, so it can be abstracted in some kind of monad source
transformer.

On the other hand, some macros operate directly on the assembly
buffer, but are not interested in the compilation state mentioned
above. An example is the peephole optimizing '+', which might combine
with some previous assembly operation. This kind of macro is most
comfortly implemented using pattern matching.

Now, observing this, the following pops up: there are actually 2
stacks, which i'll name the compilation stack, and the assembly
stack. The first class operates (only) on the former, while the second
class operates on the latter. Both are joined using some monadic
syntax transformation.

I say that again: 2 different sublanguages, each operating on their
own stack, are merged into one that operates on both, using some
language transform that performs the merging. 

One of the languages uses pattern matching (multimethods) in its
implementation, which is largely a problem domain issue: easier to
separate optimisation clauses.


Basicly, the assembly stack contains either function calls (which
generate some result at run time) or quotations. CODE or DATA. If it
is data, it can be used in partial evaluation. If it's code, it needs
to be compiled.

The picture in PURRR18 is a bit more complicated due to the use of
other macros that generate inline machine code, but the principle is
the same.

Now, the consequence of this is that it is not so difficult to
implement a reasonably powerful metalanguage with partial evaluation
using only a simple recursive macro construct, as long as the
primitives are powerful enough. The real trick is to reduce the number
of primitives.