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.
> From: Marc Feeley <feeley@xxxxxxxxxxxxxxxx>
> 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).
Do you agree that what you are proposing violates the r5rs
specification of delay? If so, do you really think it's worth the
incompatibility? Perhaps you should use a different name, like
dynamic-delay. Dynamic-delay can be portably implemented as shown
below, at least with respect to a single-threaded r5rs system with
dynamic-wind:
(define-syntax dynamic-delay
(syntax-rules ()
((_ expr)
((call-with-current-continuation
(lambda (k1)
(lambda ()
(delay (call-with-current-continuation
(lambda (k2) (k1 (lambda () (k2 expr)))))))))))))
(let* ((x #f)
(promise (delay x)))
(dynamic-wind
(lambda () (set! x #t))
(lambda () (force x))
(lambda () (set! x #f))))
=> #t
(let* ((x #f)
(promise (dynamic-delay x)))
(dynamic-wind
(lambda () (set! x #t))
(lambda () (force promise))
(lambda () (set! x #f))))
=> #f
-al