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.
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