Is the signal system of Elm available as a Haskell library?

Question

For the task I'm working on, the signal system of the Elm programming language seems to be an appropriate solution.

But my pure computational functions are implemented in Haskell. Is there a Haskell library that would allow me to construct a signal graph (with my pure functions in the nodes) so that it works like in Elm?

My background

I need to observe intermediate results of a huge computation, on demand, i.e., I don't want to actually format and output each intermediate result, but if it is requested, then I should respond with the most fresh intermediate result (received from the computation signal).

Actually, there are several parallel computations, and some of them use the result of others, so I want several independent output signals for observing them. So I believe I could write an Elm program modeling the system to observe the intermediate results as they are available. (Perhaps, I'm wrong, I should try to write a prototype at least in Elm probably, but I'm also thinking about integrating with my main Haskell code already.)

Indirection

There are a number of Haskell FRP packages. I think you should probably dig through those before trying to port something from Elm. – Mendy

A few things from this area are mentioned in the disccussion of a new Auto library. Now I suspect that I need something more like a real ("real-time") FRP rather than a pseudo FRP like Elm or Auto, because I want for a dependent node to perform a new computation only whenever it is free in the real-time (done its previous job), and it should take whatever intermediate result from the source node is available at that moment, skipping any previous ones, and not waiting for new ones... – Indirection

On a low level, I imagine this as a mutable variable holding the last computed intermediate result (in the source node), and the dependent node reading it whenever it is free again. Or better: whenever it is queried, and hence must force the computation of its value. Well, the last part is not so unsimilar from the Elm system, but matching my idea that the source signal is like a mutable variable with the Elm system is not yet clear for me. Anyway, these considerations of mine are not directly related to the question I posed in the title of this post. – Indirection

Anyway, these considerations of mine are not directly related to the question I posed in the title of this post. I believe the question from the title is a very important and intersting one on its own for the Haskell community, because Elm has an attractive well-presented and widely-known signalling system, which many might want to use in their Haskell programs. – Indirection

A nice solution to the particular problem of mine could be writing my computation nodes as coroutines (see also Bargain Priced Coroutines), and then a specialized top-level main function which would connect them through a mutable variable and scheduling them in "real-time" with real threads. Then I'd have the flexibility of embedding them into a completely different scheduler (purely functional, with discrete steps, cooperative multi-tasking, or less finegrained) – Indirection

Answer 1

Helm, which I am currently maintainer of, might be what you are looking for. It does combine the signalling with an SDL window that will always appear. You might be able to hack the render function and still use Helm's Signal without SDL or you could just take inspiration from Helm and write a similar Signal type using Elerea (which Helm uses in the background).

An even better idea might be to modify Helm to allow for use cases where main might not have anything to display and send us a pull-request.

Cabral

Answer 2

From a comment by Tekmo to the announcement of "Elm 0.15: Tasks, Mailboxes, and import syntax":

The Haskell version of mailboxes is pipes-concurrency. The analog of Elm's Address is an Output and the analog of a Signal is an Input.

(BTW, this seems to be very close to what I was looking for. Initially, in previous versions of Elm, the abstractions I actually wanted seem to have been missing, but tasks and mailboxes might fit my needs quite well. So, and now I know--thanks to the comment by Tekmo--that a similar Haskell library is pipes-concurrency.)

Indirection