[bitc-dev] bitc and coroutines
sam at samason.me.uk
Sat Dec 2 19:15:12 CST 2006
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
More information about the bitc-dev