On Sat, Dec 02, 2006 at 03:40:11PM -0500, Jonathan S. Shapiro wrote: > I don't know > if he has published that as a TR yet. If not, I'll kick his butt > appropriately tomorrow. Swaroop: you've been warned! :-)
I'm glad you're not my professor! :) > > > I'm not convinced that the language should provide > > > support for threading or co-routines. Speaking from my perspective as a > > > programmer, most language support for these features is badly flawed. > > > > There never seems to be enough thought put into the design of these > > things... > > It is always tempting to say that, but I think this is not the real > culprit. I think the real issue is that concurrency is a lot harder than > we want to believe, even in its simplest forms. I was mainly thinking about the Python coroutine implementation when I said this. It has a very asymmetric interface where only the initiator of a coroutine can specify which coroutine they want to resume. The callee doesn't have this ability, and just has to blindly "yield". This was quite a problem for me as the code I was writing were naturally expressed as callers, but I couldn't write the bit of plumbing to fit in the middle---maybe if I come back to the problem in a couple of weeks it will all be obvious, but I have a feeling it won't. The history of coroutines in Python, that of generators, makes the chosen evolution natural---but it's still annoying. > For example: co-routines generally turn into event dispatch, and there > is often some non-determinism about what co-routine runs next. This > introduces a *huge* problem for program analysis. Yes, I agree that those are bigger and much harder problems. I'm annoyed about things almost being first-class objects, but not quite. I don't know much about the history though, so it just seems silly to me. I'm not even sure if I would have done anything different from them in the situation. Sam _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
