This page is part of the web mail archives of SRFI 39 from before July 7th, 2015. The new archives for SRFI 39 contain all messages, not just those from before July 7th, 2015.
> Note that the lambda form does not close over the dynamic > environment so why should it be different from delay? Well if you > did this the "dynamic environment" would in fact be the lexical > environment so you would lose all the benefits of dynamic binding. > When one writes a function with lambda there is an expectation that > the dynamic environment is abstracted over. However when using a > DELAY the expectation is that only the evaluation time is changed, > not the computation being performed (unless side-effects are > performed that expose the evaluation order). I'm afraid I can see problems with that characterization of delay. I'd also like to show an example that seems to demonstrate why delay should _not_ be closed over the dynamic environment. It is sometimes convenient to invert an iteration "inside-out" -- turn an iteration over a collection into a lazy list of the traversed elements. Generators in Icon, Ruby and now Python use a similar trick. Here's a generic iteration inverter: (define (foreach->lazy-list foreach-fn collection) (delay (call-with-current-continuation (lambda (k-main) (foreach-fn (lambda (val) (call-with-current-continuation (lambda (k-reenter) (k-main (cons val (delay (call-with-current-continuation (lambda (k-new-main) (set! k-main k-new-main) (k-reenter #f))))))))) collection) (k-main '()))))) We can see how it works: (define (force-print lazy-lst) (let ((lst (force lazy-lst))) (if (pair? lst) (begin (display (car lst)) (newline) (force-print (cdr lst)))))) (force-print (foreach->lazy-list for-each '(1 2 3))) We should point out the expression (delay (call/cc (lambda (k) ...))). It is critically important that 'k' be the continuation in the 'forcing' expression rather than the continuation of the 'delay' expression. Indeed, it is the former. That seems to contradict to the quoted assertion that 'delay' merely delays the time the computation is performed. If it were, in (let* ((x (delay (call-with-current-continuation (lambda (k) (k 1))))) (_ (display "once")) (y (force x) )) (list (integer? x) y) ) 'k' would have been the continuation that delivers the result to x. In reality, 'k' delivers the result to 'force'. > This is consistent with the concept of delaying the > computation (you only want to change **when** the computation is > performed, not **what** the computation performs) In the case of call/cc, it is important *what* is performed (and *where* it is performed). Let us consider what happens when we try the following: (define (for-each-str iteratee str) (with-input-from-string str (lambda () (do ((val (read) (read))) ((eof-object? val)) (iteratee val))))) (force-print (foreach->lazy-list for-each-str "4 5 6 7")) The following subexpression of foreach->lazy-list (k-main (cons val (delay (call-with-current-continuation (lambda (k-new-main) (set! k-main k-new-main) (k-reenter #f)))))) executes in the dynamic context when (current-input-port) is the string port. Therefore, 'delay' is evaluated in this context. Suppose delay is closed over the dynamic environment. Our delay thus captures the fact that (current-input-port) is the string port. After the delay and cons are evaluated, k-main is invoked, which switches (current-input-port) to that of the main program. The main program later on forces the cdr of the lazy list. This forces our delay -- which restores the binding of (current-input-port) to the string port. Then k-reenter is executed, which re-enters the scope of with-input-from-string and swaps the current binding for the input port with that for the string port. Both bindings however are the same. Therefore, when we re-escape after the iteration, the input port remains bound to the string port. Thus the act of forcing a lazy list has corrupted the binding of the input port in the main program! > If this inheritance did not happen, the DELAY form would lose modularity (in > the sense that the one writing the DELAY expression would have to take > into account all the possible places where the promise is forced). I guess that is the reason why a non-strict functional language must be pure.