Fri Jan 21 11:36:03 EST 2011

Racket-based DSP eDSL specs: simple abstract interpretation.

  - Simple DSL, should really not be more than algebra.
  - API Code analysis through multiple interpretations (abstract interpretation)

General Architecture

I'd like to take the best ideas from the Carette, Kyseljov, Chan in
their typed approach (MetaOCaml and Haskell) and apply them to my more
familiar Racket (PLT Scheme) environment:

  - Syntax as functions instead of data structures, implemented as
    module _interfaces_.  ( I think this is the initial vs. final
    algebra idea -> FIXME: expand on this. ).  The

  - Abstract domains interpretations implemented as module _instances_.

In Racket it seems a good approach is the "sandwich" architecture.

  * Application components are implemented as units in terms of the
    num^ signature which implements the abstract domain on which the
    code operates.  The programmer has complete freedom in naming and
    composing units.

  * Analysis and code generation are performed by instantiationg the
    num^ signature over different data types on one side, and
    providing different analysis methods on the other side for the
    exports defined by the application components.

An example: to perform code generation, the monad approach can be
side-stepped, and the num^ operations can be implemented in a stateful
manner, i.e. using scheme parameters, with the top level defined by
the driver side of the sandwich.

This trades some risk for a simpler interface.  This was the hardest
decision, as it cuts the deepest.  I intend to make up for the lack of
static typing and referential transparency by providing many abstract
domains for analysis.  An advantage is that the recently proposed
partial-continuation approach to code generation probably can be used
without too much adaptation.

Implementation and Sugar

I would like to use a scheme #lang that has the following two elements:

  - Phase 0 bindings all defined as abstract operations in terms of
    the num^ interface, allowing different interpretations.

  - Macro language is scheme with all usual bindings available to
    construct non-functional compile time DSL language features.