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
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_
All this is because of subtle differences is between `code', `closure'
and `continuation'. (I need a better name for `closure' though.)