Connecting the Wolfram Language to Haskell

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Connecting the Wolfram Language to Haskell

GHC - devs mailing list

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 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 <[hidden email]>
Subject: Haskell question, etc.

 

       

Simon ---

[…snip…]

 

What brings me to email is a Haskell question:

It's probably best that I just forward what my team wants to ask:

=========

A powerful feature of the Wolfram Language is that it allows users to evaluate code in other programing languages, returning the results to a Wolfram notebook (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freference.wolfram.com%2Flanguage%2Fguide%2FExternalInterpretedLanguageInterfaces.html&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cb8abce5772944182a1de08d7d5d68940%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212989714565411&amp;sdata=po6qg70bq8f4jbEvTRv6eoQfhLSZ3Fvdj3DBJFpWB%2FY%3D&amp;reserved=0). We have implemented this feature for a number of languages, including Python, NodeJS, Julia, and Ruby. We would very much like to include Haskell in this set, but we have little Haskell expertise, and have hit a stumbling block. We would appreciate it if some Haskell experts could help us out with this feature.

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.

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

ZeroMQ is used as the transport between Wolfram Language and the external language interpreter, and JSON is the data format we use to return results. Beyond the basics of hooking up GHCi for this type of session use, we also would like assistance in introspection of Haskell results so that they can be sent back to WL in the most useful form. This is the general structure of what we do for other languages:

     if result is an object
         return object data
     else if result is a function
         return function data
     else
        return JSON form of the expression

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.


========




Any help greatly appreciated!  (Not least because I'd personally like to play with this... :) )

--- Stephen


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

start_Haskell.hs (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Connecting the Wolfram Language to Haskell

Ben Gamari-3
Simon Peyton Jones via ghc-devs <[hidden email]> writes:

> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Connecting the Wolfram Language to Haskell

Compl Yue
In reply to this post by GHC - devs mailing list
Hi,

If you are already running atop the Jupyter technology stack, IHaskel [1] may be very straight forward to be incorporated from technical aspect (while licensing aspect is out of my expertise).

But still I would like take this opportunity to have more/further evaluation from you, about [2] , with by far my implementation [3] and application [4].

Once a frontend plugin can be injected into a GHCi session, and hooked up to some interactive UI, a new door is opened to allow much easier setup & use of GHC API interactively, like demonstrated in Hadui [4].

Currently there are too many different ways to setup a GHC API session, HIE has tried hard to unify them, but itself is yet under transition. I see the frontend interface being a proper abstraction even extended to WebUI/GUI applications, making interactions perfectly decoupled from how the underlying artifacts are organized, thus worth further consideration.

While IHaskell is more powerful and better established as with Jupyter notebook, I chose the frontend route because IHaskell didn't come to today's maturity when I needed something like Hadui, and ZeroMQ seems bloating to my cases, even for now.

Cheers,
Compl

[1] https://github.com/gibiansky/IHaskell

[2] https://gitlab.haskell.org/ghc/ghc/issues/17348

[3] https://gitlab.haskell.org/complyue/ghc/tree/ghc-8.6-ife

[4] https://github.com/complyue/hadui


On 2020/5/1 上午5:13, Ben Gamari wrote:
Simon Peyton Jones via ghc-devs [hidden email] writes:

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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs