A few thoughts. The envisioned Python-Haskell bridge would have two directions: 1) calling Haskell code from Python; 2) calling Python code from Haskell. The proposal spends more space on #1 but I think #1 is both more difficult and less interesting. By "Haskell" I presume you mean GHC. I think that the GHC runtime doesn't embed very well, despite the example on the Python wiki (http://wiki.python.org/moin/PythonVsHaskell near the bottom). This is especially if you want to use the concurrency stuff. The GHC runtime wants to trap the timer interrupt and do select based i/o among other things. And I'm not sure that wanting to call large Haskell components under a Python top-level is that compelling: why not write the top level in Haskell too? The idea of making the critical components statically typed for safety is less convincing if the top level is untyped.
There is something to be said for porting some functional data structures to Python, but I think that's mostly limited to the simpler ones like Data.Map (which I've wanted several times). And I think this porting is most easily done by simply reimplementing those structures in a Python-friendly style using Python's C API. The type signatures (among other things) on the Haskell libraries for this stuff tend to be a little too weird for Python; for example, Data.Map.lookup runs in an arbitrary monad which controls the error handling for a missing key. The Python version should be like a dict, where you give it a key and a default value to return if the key is not found. Plus, do you really want Python pointers into Haskell data structures to be enrolled with both systems' garbage collectors? (Actually (sidetrack that I just thought of), a Cyclone API would be pretty useful for writing safe Python extensions. Cyclone is a type-safe C dialect, see cyclone.thelanguage.org ). The Haskell to Python direction sounds more useful, given Haskell's weirdness and difficulty. Python is easy to learn and well-packaged for embedding, so it's a natural extension language for Haskell applications. If you wrote a database in Haskell, you could let people write stored procedures in Python if they didn't want to deal with Haskell's learning curve. Haskell would call Python through its "safe" FFI (which runs the extension in a separate OS thread) and not have to worry much about the Python side doing IO or whatever. Of course this would also let Python call back into the Haskell system, perhaps passing Python values as Data.Dynamic, or else using something like COM interface specifications. Anyway I'm babbling now, I may think about this more later. -- http://mail.python.org/mailman/listinfo/python-list