Connecting the Wolfram Language to Haskell

Friends
Short summary: can someone familiar with using the GHC API offer advice on getting the Wolfram Language connected to Haskell?
Many of you will know of the Wolfram Languagehttps://www.wolfram.com/language/, which is IMHO pretty cool and not well enough known. There are lots of interesting things about it, but a huge thing is that it's deeply connected to the vast pile of carefully curated data that Wolfram Research has gathered and organised over several decades.
Anyway, they'd like to be able to invoke Haskell code from the Wolfram Language interpreter. But as you'll see below, they are understandably stumbling on the engineering aspects of doing so.
Rather than spam Stephen Wolfram himself, I'm cc'ing Todd Gayley who is the team lead. (Hi Todd.) I'd really appreciate it if some of you could help advise him. It would be terrific to have a direct connection between Wolfram and Haskell!
Many thanks
Simon
From: Stephen Wolfram
Sent: 01 April 2020 01:49
To: Simon Peyton Jones

Simon Peyton Jones via ghc-devs
Friends
Short summary: can someone familiar with using the GHC API offer advice on getting the Wolfram Language connected to Haskell?
Hi Todd, et al., This sounds like a great project. I have fond memories of Mathematica from my studies. ...
We have the following basic line of code for evaluating a string of Haskell code:
r <- liftIO $ runInterpreter $ do { setImports ["Prelude"]; eval strToEvaluate}
The problem is that this is a one-shot evaluation, and we want a long-lived interactive Haskell session, to which a series of inputs can be directed. We have been told that we have to use GHCi for that, but we don't know how to do it.
It appears that you are using the `hint` library [1] for evaluation. I'll admit that I've not used hint; it looks quite sensible but I do not know what limitations you might encounter. It looks like its approach to error handling may leave something to be desired. Nevertheless, we can work with it for now; if we run into its limitations then the alternative is to use the GHC API directly, as suggested by Simon.
The basic flow of our functionality is as follows:
1) User calls StartExternalSession["LanguageName"] to launch an interpreter for the language. This process remains running and can be used for multiple calls.
2) User calls ExternalEvaluate[session, "some code"] to execute the given code in the external language and return a result converted into native Wolfram Language types (strings, numbers, lists, associations, etc.)
Sure. ...
We have attached a simple file of Haskell code that one of our engineers has successfully used to get a basic evaluation of Haskell code from the Wolfram Language, but it uses the single-shot evaluation code that was given above, and so is not suitable. We would appreciate any help that you can give us, or developers or resources you can point us at, to assist in integrating Haskell into our ExternalEvaluate system.
It looks like you will want to push the `runInterpreter` out of the `forever`. Afterall, you want the interpreter session to persist over multiple requests. Doing this isn't difficult but does require some monad transformer shuffling, which may be unfamiliar to someone coming from another language. I've put up a cleaned up version of your program here [1]; hopefully this is enough to get you started. Do note that this requires a patched version of zeromq4-haskell due to a minor bug [2] which I have fixed [3]. Do note that there is a related effort, iHaskell [4], which provides a Haskell kernel for Jupyter Notebook. This might be a place to draw inspiration from. Let us know how things go and don't hesitate to be in touch if you have questions regarding the GHC API. Cheers, - Ben [1] https://github.com/bgamari/zeromq-hint [2] https://gitlab.com/twittner/zeromq-haskell/-/issues/66 [3] https://gitlab.com/twittner/zeromq-haskell/-/merge_requests/6 [4] https://github.com/gibiansky/IHaskell
participants (2)
-
Ben Gamari
-
Simon Peyton Jones