René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"python-csp syntax overhall","articleBody":"From old Google Code repo:\n\nThink about whether python-csp \"syntax\" is optimal. The thoughts below are from an ancient email thread, never implemented:\n\nOne is that I would like to see `Process`es, `Par`s, `Seq`s and `Alt`s (and `Barrier`s / `Bucket`s / ... 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:\n\n``` python\nmyProc() // [myAlt(), mySeq(), myPar(), myChannel()]\n```\n\nand all of those would run in parallel.\n\nClunky 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. `Guard`s are for synchronising on and processes\nare 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 `Guard`s 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.\n\nA 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 `Barrier`s the base class for guards, and\nhave `Channel`s extend the `Barrier` class and change round all the method names to suit.\n\nThis 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. `Bucket`s 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.\n","author":{"url":"https://github.com/snim2","@type":"Person","name":"snim2"},"datePublished":"2012-10-03T18:57:01.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/17/python-csp/issues/17"}