Neil Toronto wrote:
There's an elephant-in-the-living-room UI problem, here: how would one go about extracting a partial order from a programmer?
Beat him or her with a stick? Just kidding of course. ;-) I think what you mean is how can we make it easier for a programmer to express their intention. One way is to provide a rich set of alternatives in extension modules and letting them choose. The ones that work will bubble up to the top, and the hard to manage and maintain choices will either be improved or forgotten.
A text editor is fine for a total order, but I can't think of how I'd use one non-messily to define a partial order. How about a Gantt chart for a partial order, or some other kind of dependency diagram? How would you make it as easy to use as a text editor? The funny thing is, once you solve this problem, it may even be *easier* to program this way, because rather than maintaining the partial order in your head (or inferring it from a total order in the code), it'd be right in front of you.
Well, you wouldn't want to interleave several tasks instructions together in any fixed (or otherwise) way. That definitely would not be anything I would want to maintain. Being able to define serial blocks of code to execute in a parallel fashion can make some things easier to express because it gives you another way you can group related code together instead of having to split op, or combine unrelated, code together because of ordering dependencies. But addressing your partial order concerns, most likely you will have parallel structures communicating to one another with no apparent predefined order. The ordering could be completely dependent on the data they get and send to each other, and completely dependent on outside events. Think of tasks that can open multiple communication channels to other tasks as needed. What order would these be executed in? Who knows! <shrug> And you may not need to know. It may be that a partial-order execution order could be considered a subset of indeterminate execution order.
There's no reason a program with partial flow control couldn't have very Python-like syntax. After reading this, though, which formalized what I've long felt is the biggest problem with concurrent programming, I'd have to say it'd definitely not be Python itself.
I think it would still be python. From what I see Python will continue to be improved on for quite some time. But these ideas must prove themselves to be pythonic before they get put in python. (My spell checker picked out polyphonic for pythonic... PolyPython?)
For the record, I disagree strongly with the "let's keep concurrency in the libraries" idea. I want to program in *Python*, dangit. Or at least something that feels a lot like it.
My guess, (if/when this is ever added), it will most likely be a combination of some basic supporting enhancements to names and objects so that they can work with task libraries better, along with one or more tasks/multi-processing libraries. If it turns out that the use of some of these ideas becomes both frequent and common. Then syntax similar to the 'with' statement might find support. But all of this is still quite a ways off unless some (yet to be identified) overwhelming need pushes it forward. Just my two cents, _Ron