Joe Marshall wrote: > Similarly with threads. These are a disaster. It is very hard to program > with > concurrency. It is harder still if your concurrancy mechanism is something > as primitive as a thread. In nearly every implementation of Common Lisp > I've worked on, they've made major errors in concurrency control. And these > are the *vendors*. The users have no hope of getting it right. > > I don't know what the correct solution to concurrency is, but I'm sure we > can do better than a thread library.
I don't know what the correct solution to control flow is, but I'm sure we can do better than first-class continuations. My point being that the reason for providing something like threads shouldn't really be for most "users", it should be for the people who want to build libraries and frameworks that those users can use. Supporting that requires something very general but also low-level. That solution will not necessarily be something that "users" should be using directly in their applications, typically. This has been one of the strengths of Scheme - in the words of RnRS, it is "flexible enough to support most of the major programming paradigms in use today." That claim should extend to concurrency paradigms. Anton _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
