Description
From old Google Code repo:
Think about whether python-csp "syntax" is optimal. The thoughts below are from an ancient email thread, never implemented:
One is that I would like to see Processes, Pars, Seqs and Alts (and Barriers / Buckets / ... if possible) as combinators in python-csp that are all "first-class" and can all take one another as arguments to their constructors. It would be nice and elegant to avoid special cases here. So we could say things like:
myProc() // [myAlt(), mySeq(), myPar(), myChannel()]and all of those would run in parallel.
Clunky syntax, the issue now is that we're close to this in python-csp, by having only two sorts of base classes in the library: processes and guards. Guards are for synchronising on and processes
are for computation, but a guard cannot be "run" like a process can and a process does not implement read / write / select like a guard does. Python works by duck typing, so the real difference between Guard and Process types is that the latter implements a start method which starts a process running, and Guards can "read" and "write". Barriers break this model entirely because we have used Channels() as being the default sort of guard, which I'm now beginning to question.
A very simple way to unify guards and processes would be for an Alt, when it "runs" to have an infinite loop which repeatedly calls Alt.select() (and variants of that for priority selection, etc). Equally, we could have ReadChannel() and WriteChannel() classes which read() and write() indefinitely, and so on. I'm not sure how the converse would work by allowing processes to be synchronised on, but the answer could be to make Barriers the base class for guards, and
have Channels extend the Barrier class and change round all the method names to suit.
This is relatively simple to implement, but I'm not entirely sold on it as a way forward. Firstly, when synchronisation primitives get more complicated I'm not sure if the model will break down. Buckets are something we'll want to have for our own work on pervasive computing and no doubt there will be other useful primitives too. Secondly, I haven't (yet) written a nice CSP model of all of these ideas, but i think it's worth doing, not so much to check deadlocks as the scheme is quite simple, but really to get a better idea of the style of programs which might result.