Moving ahead Marc Feeley (07 Mar 2003 22:09 UTC)
Re: Moving ahead felix (08 Mar 2003 13:40 UTC)
Re: Moving ahead Marc Feeley (08 Mar 2003 14:38 UTC)
Re: Moving ahead Alhambra Petrofsky (08 Mar 2003 17:09 UTC)
Re: Moving ahead Marc Feeley (09 Mar 2003 03:40 UTC)

Re: Moving ahead Alhambra Petrofsky 08 Mar 2003 17:09 UTC

> From: Marc Feeley <xxxxxx@IRO.UMontreal.CA>

> 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