[r6rs-discuss] [Formal] SRFI-39 should be made an R6RS library
bear wrote:
> I think that the interaction of threads and continuations is *Necessarily*
> hideous, especially in the presence of mutation. It may be a mistake for
> the same language to even have both. At the very least one ought to be
> well-defined in terms of the other.
>
Hmm. I'm not so sure about the "*necessarily* hideous" part but
strongly agree about defining threads in terms of continuations.
If one has non-deterministic interrupts, and continuations, then one has
threads. As with C's sequencing points, there are (only) specific
points in the execution of a serial segment of Scheme code where a thread
switch is permitted but that is a very fine-grained limitation.
Threads are fine, regardless of implementation, if the effect is "as if"
we were witnessing an interrupt driven, serial execution of continuations.
I think the big thing that is missing, to make things *not hideous*,
is (I hope I'm using the terminology correctly), delimited continuations.
In Guile Scheme (even absent true threads), I found it useful to
have a construct like:
(call-with-one-shot-continuation (lambda (k) <body>))
Many variations are possible. The idea is that K is a continuation
for the whole form and is the same continuation with which
<body> is implicitly executed. The catch is that the second (and
all subsequent) times that that continuation is executed, instead,
an error is raised. I have no strong opinion about how that error
is handled... I think it would be fine if it were required to abort the
entire program execution.
One can implement call-with-one-shot-continuation in R5RS Scheme
but it deserves promotion to the language as a core concept because
it cries out for special implementation. (Similarly,
call-with-upwards-only
-continuation and call-with-upwards-one-shot-.....)
Given a construct such as that, one could then define something
like PARALLEL-MAP. At first glance, the "fortress" programming
language appears to have gone this route, making PARALLEL-MAP
the default because of its significant utility in a lot of scientific
programming.
-t
Received on Mon Feb 12 2007 - 15:16:28 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC