[<<][staapl][>>][..]
Wed Sep 17 08:27:54 CEST 2008

algebraic types

I've been selling the pattern matching as being based on algebraic
types.  Maybe it's time to make that a bit more formal?

The most interesting problem to solve is to perform type analysis on
the macros.  Is it possible to compute every in-out behaviour?

The reason for asm code to be in source form is mostly confusion about
what to do with it where it to be an abstract data structure.

Maybe the most important changes are:

   * replace the extensional composition mechanism by an intensional
     one so type interference can reach the primitives.

   * add annotation to primitives. (done)


The first one is less straightforward..  This is simple for anything
not built on top of parser extensions..  Looks like the parser needs
to be rewritten for this.  That's a lot of work...  It's probably
better to try to incrementally improve it. Make it more abstract..

One thing I don't like is the way parameters are used to record the
'closing' of expressions.  It might be better to make 'expr' an
abstract data type (zipper?) and encode all the information in it.

First part is quite simple: it's only the immediate/function sites
that need modification for the normal syntax (not forth/parser-tx.ss)

Second part involves the 'close' operation, which can be separately
abstracted.  Let's first remove this.  It's trivial for the pure
concatenative code, but not for parser-tx

OK. got a better idea now about intensional representation: all the
parser macros convert ultimately to pure concatenative code through
the quotation mechanism.  The only thing parser-tx does is to add
dictionary functionality.  It looks like replacing the default lambda
wrapper is all that's necessary.

Then, the "current-close" operation is only used in the locals-tx.ss
transformer.

It's not just the default lambda wrapper, it's also the assumption
that the initial state has a syntactic representation.  Let's try to
model the expression as a function parameterized in the internal state.

Got first draft of functional representation working:

(define (rpn-open-expression) (lambda (x) x))
(define (rpn-on-cursor fn expr) (compose fn expr))
(define (rpn-close-expression expr)
  (let ((s #'*state*))
    #`(lambda (#,s) #,(expr s))))
(define rpn-expr? procedure?)

Next: fix locals, since it's broken now.  This is the one that needs a
cursor, since it needs to wrap the code.  This uses a non-hygienic
name capture trick that apparently doesn't work in the current approach.

This needs to be factored out a bit.

I don't see a way to do this without capturing the state and
re-binding it.. So i put rpn-state back in, but it's not a paramter.




[Reply][About]
[<<][staapl][>>][..]