SoC project: Python-Haskell bridge - request for feedback

[Paul Rubin]

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.