SoC project: Python-Haskell bridge - request for feedback

[Michał Janeczek]

Thanks for finding time to reply!

On 26 Mar 2008 01:46:38 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:
> 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.

I wasn't aware of the runtime issues, these can be things to watch out
for. However, the type of embedding that I imagined would be mostly
pure functions, since Python can deal with IO rather well. It'd also
be applicable in situations where we want to add some functionality to
to existing, large Python project, where the complete rewrite
would be infeasible.

>  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?

I didn't mention this in this first draft, but I don't know (yet)
how to support those "fancy" types. The plan for now is to export
monomorphic functions only. As for GC, I think having the two systems
involved is unavoidable if I want to have first class functions on
both sides.

>  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.

That is one of the use cases I have missed in the first draft.
Thanks for the idea!

>  Anyway I'm babbling now, I may think about this more later.
By all means, please do go on :) This has helped a lot :)

Regards,
Michal