Sun Jan 4 14:42:10 CET 2009

Staapl definition

Staapl is a 2-stage concatenative language inspired by Forth, Joy and
Scheme.  It is built as follows:

  - [MACRO LANGUAGE] Semantics are defined in terms of primitive
    machine code transformers: each WORD is represented by a function
    mapping a string of machine code instructions to another one.

    Note this entails both EXPANSION and RECOMBINATION of
    primitive machine code: Macros perform computations.

  - [CONCATENATIVE LANGUAGE] Because the transformers are functions,
    function composition can be used as the language's composition
    mechanism.  This is represented syntactically by CONCATENATION.

  - [STACK LANGUAGE] These transformers operate on ONE END of a
    machine code strings which makes it easy to attribute the
    semantics of a STACK language.

  - [INSTANTIATION] The MACRO semantics is extended with run-time
    storage and indirection (2 stacks + machine's indirect jump
    unstruction) to provide run-time operations that mimick the
    semantics of the stack-of-code transformers.

The result is a Forth-like language with a well-structured macro

It is 2-stage because of the existence of 2 very distinct code levels:
   - base machine language
   - machine language transformers

The transformers themselves can be programmed using mult-level
techniques (I.e. Scheme macros) if necessary.

A different semantics model ignores the explicit distinction between
target code generators and instantiated targed code (MACROs and
PROCEDUREs), and defines a program as a partial evaluation of a
functional concatenative program.  The main idea is to combine the
macro semantics with concrete semantics of the base machine language
to get to this simplified semantics.  However, in Staapl this is only
approximate and acts more like an ideal design guide.


I'm happy with this in the sense that it is a story that keeps coming
back, and it is fairly close to how it is implemented.  However, the
instantiation part isn't very clear yet...  This needs a proper
mathematical model: i guess the instantiation part will need proper
constraints.. I.e. it's easy to define for pure functions operating on
machine values, vs. transformation of literal load instructions, but
this has to be made more explicit.