Marc Feeley wrote:
>
> It appears that the best solution in this case is to separate the
> issues into several SRFIs. SRFI-39 can specify the parameter API and
> the behaviour in the absence of threads. It will be up to individual
> thread SRFIs to specify a particular semantics to dynamic binding.
Good idea.
> There is however the issue of the interaction of dynamic binding and
> the DELAY special form. In my opinion the body of the DELAY form
> should be evaluated in the same dynamic environment as the DELAY form
> itself. For example in the code
>
> (with-output-to-file "foo"
> (lambda ()
> (let ((x (delay (display "hello"))))
> (with-output-to-file "bar"
> (lambda ()
> (display "world")
> (force x))))))
>
> we want "hello" to go to the file "foo" and "world" to go to the file
> "bar". 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). 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).
> This implies that if an exception is raised by the body of a DELAY
> form, it is the exception handler that was current at the DELAY form
> that is invoked. I think this makes sense, but I'd like a discussion
> on this before moving ahead with the rewrite.
>
Is it really necessary for SRFI-39 to specify this? As per R5RS `delay'
and `force' are defined clearly without capturing the dynamic context.
So in the obvious implementation of `with-output-to-file' (via `dynamic-wind')
promises would not retain the dynamic environment and your example
would not behave as you intended.
Moreover, it might be useful to change the context in which the force
happens (say, I'd want to redirect output to a log file, or a custom
`tee' port).
So I propose to leave `delay' + parameters unspecified. That's another
can of worms altogether...
cheers,
felix
