Wed May 21 19:39:42 CEST 2008

Compiler specialization: bottom up with holes?

This is a justification for the violation of Staapl's bottom op code
structure.  Code transformers living in the '(macro) namespace, can be
arbitrarily mutated, to allow a cross-cutting specialization without
too much red tape.  This allows the core language implementation to be
separated from optimal target implementation, which replaces primitive
operations in the core language.

The main problem this solves is the impossibility to know in advance
which primitive code generators need to be replaced for a specific
target.  The main problem this introduces is that it is unrestricted.

Properties of this system:

  * All '(macro) transformers are boxed functions.  They can be
    replaced with specialized versions.

  * Each compiler specialization is instantiated in a separate
    namespace, making these mutations less harmful due to limited

This mechanism behaves somehow as a local 'parameterize operation, but
is implemented differently.

This could be solved using subclassing, but each ``object'' provides
only a single method, meaning that it's better modeled as a
parameterized function.

All such mutations generate events.  Currently this triggers logging
of the mutated macro to the console to keep an eye on this extension
process, until I figure out a more static mechanism that can prevent
some misuse of this mechanism:

;; \__ target
;; \__ scat
;; \__ coma
;; macro/jump     <- the 'control module redefines the 'jump macro
;; \__ control
;; macro/sym
;; macro/label:
;; macro/exit
;; \__ comp
;; \__ asm
;; \__ forth
;; \__ live
;; macro/+
;; macro//
;; macro/*
;; macro/-
;; macro/dup
;; macro/drop
;; macro/swap
;; macro/,
;; macro/or-jump
;; macro/not
;; macro/then
;; \__ purrr
;; \__ pic18