Sun Aug 23 09:35:40 CEST 2009

Making partial continuations abstract

So, it looks like it's clear that PCs are the proper abstraction
mechanism: they are k-stack segments that can be concatenated to the
current continuation.

There are several ways to approach this.  However, considering that
the tagging needs to use _linear_ memory, the appropriate way is to
tag the pairs.  If this is the way to do things, is it possible to
move other kinds of tagging to a ``snapped'' pair-based encoding?

I.e. instead of Seq(Quote(a), b) use SeqQuote(a, b)

It doesn't look like it: there are several disadvantages to not having
Quote(...) and Prim(...) as separate instances of a sub (subroutine)
type.  These are used a lot as a single type and should be bundled, so
they don't complicate matters.

So what about this:

and cont  = 
    | Next of sub * cont
    | Late of datum * cont

Where 'Late' has the implied semantics of using `interpret' to convert
datum -> sub.  This would allow certain kinds of cheap, linear
reflective behaviour to be implemented.

( Note: I'm _only_ trying to work around the construction of a Quote
type, which is nonlinear.  I.e. it is a flattening optimization that
allows the use of linear data only. )

What about calling 'Late' something like 'Data' or 'Close'.  It really
doesn't need `interpret' semantics: it can be a pure quote, because
the call to `interpret' can be inserted directly into the

This looks alright.  I just have to convince myself that this is
elegant: I.e. that it's really necessary to have 2 quotation
mechanisms: one part of nonlinear code (enabling data to behave as
code + be shared), and one part of linearly constructed code (data as
code, but not shared).  

Let's give it some fermentation..

EDIT: One thing to note is that the continuation doesn't need this
whole tail-recursive constraint: it is always consed to the empty
continuation, which leads to a machine halt state.  So it really _is_
a pair.

All this is because of subtle differences is between `code', `closure'
and `continuation'.  (I need a better name for `closure' though.)