[<<][meta][>>][..]
Fri Jan 21 11:36:03 EST 2011
Racket-based DSP eDSL specs: simple abstract interpretation.
Deliverables
------------
- 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.
[Reply][About]
[<<][meta][>>][..]