Introduction to Concurrent Programming with Stackless Python

Grant Olson has a writeup of concurrent programming with Stackless Python. There is a great deal of actual code in the article.

Obviously concurrent programming can't be mentioned without mentioning Mozart-Oz (which recently went into version 1.3.2), Erlang and AliceML. Frankly, despite my attempts, I don't understand Haskell's FRP enough to know if it fits here as well.

(while searching archives of LtU for previous interesting mentions of concurrent programming, I came accross a post about SuperGlue...note the first message containing PVR's mention of FRP)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Questions on FRP

After experimenting a bit and thinking about FRP, I am beginning to have doubts about the usefulness of fully general FRP. The problem is that when an event arrives (an argument is changed to another), then the execution graph has to be changed. For example, if in a call to Map, the input list is changed to another input list, then a relatively costly calculation has to be done to transform the execution graph based on the first list into the execution graph based on the second list. I see no advantage in this. It seems to me that FRP is best used only at the very top level of a program (where the execution graph changes rarely if at all), and that all primitives should be executed directly and not expanded into their execution graphs.

FRP at Lambda Calculus level?

Peter (or any one else),
I just saw this note about FRP in Mozart. Does lambda calculus need to be extended to support nondeterministic choice (TakeTwo)? How about the following extension of LC, is it enough to do FRP?

Stackless and PyPy

The latest PyPy release progresses in the stackless implementation as well.

tail call optimization?

The ping pong example is not well chosen, since the solution there is tail call optimization, not coroutines. I would think that a stackless implementation would have TCO, so that example leaves me wondering rather than convinced.

I've not used stackless Python, but it seems to me that :

pervasive concurrency + pervasive shared mutable state -> mess