Mon Nov 7 18:15:43 EST 2011

The Staapl compiler is an Arrow

In spirit that is, not in interface.  It behaves as one, and it would
be great to be able to implement it as one.

Arrows in Haskell use binary tuples for plumbing.  What I need is a
mechanism that can identify components by name.  This would kill
modularity somewhat (i.e. can't arbitrary nest the same types) but
would make things a lot easier to work with.

The other idea is that instead of using names as in what I'm looking
for, or arbitrarily nested binary tuples as in the Haskell Arrow
class, the states could be nested as stacks also.  This might give a
more appropriate "stacks of stacks" approach.

Anyway, let's first summarize what there is at this time:

- Compilation stack: code compilation and partial evaluation
- Control stack: local control words: if, then, begin, again
- Macro stack: implements ';' in macro nesting.
- Chain stack: collects basic blocks.

The first 2 are called '2stack' and are defined in ...
The other 2 are define in staapl/coma/state.ss as a struct derived
from 2stack with two extra components.

Let's see if I can add a coroutine stack in there without too much
trouble.  Maybe just adding a hash is already more than enough to keep
the extension in a module.

I've added an 'ext' field to the 'compiler' struct in comp/state.ss
and adjusted the matchers and constructors appropriately.  Seems to
work just fine.  Now how to access?

I see I did my best to go creative with the `state-update' macro.
This uses the `mu-lambda-struct' from vm.ss, a shorthand notation for
machine register updates, where assigment and matching are expresed by

        <reg> -> <value>
        <reg> : <pattern> -> <value>

Maybe I should make a list called "goldmine of weird ideas" ;) I'm
having deja-vu now from the time when I wrote this.

Conclusion: the state mechanism is already extendable through the
struct derivation method.

   stack -> 2stack -> compiler

These support automatic lifting / polymorphism, i,e, you can pass a
derived struct to a basic op and it will update only the derived

So yes, it should be possible to use the extension mechanism that's
already there.  However, it would make it difficult to do this using
the current modular mechanism, in that the state constructor would
need to be extended in a way that seems to interfere with the
modularity constraints..

So let's implement it as a hash table with local names, i.e. not
symbols but something that can be globally unique.