Sat Apr 12 18:05:29 EDT 2008

automatic lifting

i'm looking at this the wrong way..

this all makes so much more sense taking the stance of "automatically
lifting" a procedure whenever it is applied to a certain input
type. that's really the only thing necessary..

so what about turning this around and seeing 'state' as an object with
a method 'apply me'

imagine a conversation between STATE and FUNC.

STATE: dude, i want to apply you. what's your game?
FUNC:  i take A to A
STATE: hey, i got some A here, i'm going to use you and move on.

so, 'state' should really be a function.


so.. it's the responsability of the state to interpret the functions
applied to it, and the responsability of functions to identify

(define (make-stack data)
  (lambda (fn)
     (if (stack-proc? fn)
         (make-stack (fn data))
         (error 'type-error)))

this changes the representation from

  (lambda (x) (a (b (c x))))


  (lambda (x) ((((x c) b) a))

which really looks like RPN code :)

the 'dumb' state would be

(define (dumb data)
  (lambda (fn)
    (dumb (fn data))))

so.. is this an interpreter? looks like it.. note that in order to
optimize things, some could be unrolled:

(lambda (x) ((x c) (lambda (stack) (a (b stack)))))

this is basicly an implementation of the 'map' function: the function
implementing the state object is the monad wrapper M which contains a
type t, and it maps an incoming t->u to Mt->Mu.


  * all functions are typed, and do not need to be aware of state.
  * state is completely abstract

maybe this can do all kinds of lifting automatically? i.e. scheme
functions -> stack functions etc..

how hard is it to change this? where do control words fit in, since
state is no longer passed automatically. maybe control words are just
another type that take a continuation argument?

(define (stack lst)
  (lambda (fn)
      ((stack/control? fn)
           (lambda (k) (fn k lst)))))
      ((stack/data? fn)
       (stack (fn lst))))))

well.. it's an interpreter for sure. can these contitionals be
eliminated? well yes, if at compile time the type can be
determined.. so is that possible? can functions be typed statically?

there's one problem though: composition: what type does this have?
state -> state, where state is a fn. so there's a difference between
'primitives' and 'composites'.

(lambda (x) ((((x) a) b) c))

EDIT: something's chicken and egg here tho: primitive types and
extensible types. looks like i slammed into the "expression problem",
since i want to extend both the type and the methods.