[<<][staapl][>>][..]
Fri Apr 24 23:31:28 CEST 2009

list interpreter

Why not use a forth-style list interpreter?  Why does the code have to
be abstracted as a nested lambda expression?  What about CPS?

I'm a bit confused now..

Let's see.. The goal is to be able to run the code without excessive
consing.  This means either nested expressions:

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

List interpretation:

          (lambda (stack)
            (do-list (list a b c) stack))

Or CPS:

          (lambda (stack k) ;; L1
            (a stack (lambda (stack1) ;; L2
                       (b stack1 (lambda (stack2) ;; L3
                                   (c stack2 k))))))

With a,b,c primitives.
[1] http://en.wikipedia.org/wiki/Continuation-passing_style



Funny, writing the CPS as follows makes it easier to see the
Haskell "do" notation (with arrows reversed).


(define (add p k)
  (k (cons (+ (car p)
              (cadr p))
           (cddr p))))

(define (add3 p k)
  (add p (lambda (p1)    ;; add p -> p1
  (add p1 k))))          ;; return p1

(define (add4 p k)
  (add p  (lambda (p1)   ;; add p  -> p1
  (add p1 (lambda (p2)   ;; add p1 -> p2
  (add p2 k))))))        ;; return p2

(define (comp a b) (lambda (p k)
    (a p (lambda (p1)
    (b p1 k)))))


So.. I see no advantage in CPS.  Does PLT optimize this to a simpler
form?  The closures are really no better than te naive consed return
stack used earlier.  It's probably best to stick to the native
representation.

So..  Nothing better.  But there's one optimization that should be
possible.  Instead of using 1->1 functions, it might be possible to
use n->n functions, which eliminates construction of the state vector.



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