> I think this would be a great improvement over the difficult and
> bug-ridden thread management paradigms of conventional languages.
What is so bad about other conventional languages' threads, and what
are those languages?
I am not used to threads, and most concurrency I wrote was based on
fair-threads or on the actor model à la Erlang.
In both cases, I found this elegant *and* practical, as I do not stick
to one concurrency model for all tasks.
Just like, in Scheme/CL, I may program functional, or object, or
imperative, I like to have several flavors of concurrency.
Which makes me wonder : couldn't we, for this coming Scheme, do something new?
I am thinking of defining in the standard (of Thing One or Two, I do
not know. Or maybe in Bidule, a parallel extension to Thing {1,2})
*several* possible
concurency models. And concurrency inclined implementations would pick
one or several such paradigms and implement them.
There has been much research on concurrency in Lisp dialects, and the
ideal models (as of today) may have already been designed.
I don't see concurrency/parallelism as a SRFI, and *maybe* not as a
required part of language. Rather as an optional part of the language
(ie: "you don't have to implement it, but if you do, it must be done
like this").
A couple of papers on concurrency/parallelism in Scheme that might be
of interest for those who never read about that
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.89
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.6613
P!
(sent twice. Sorry.)
--
Français, English, 日本語, 한국어
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
