[Haskell-cafe] ANN: Elerea, another FRP library

[Patai Gergely]

> But expressions that use unsafePerformIO might get inlined.
That's true, but given the way this interface is used, this doesn't seem
to be an issue, since there are typically no unsafePerformIO's hidden
deep inside an expression without a chain of Elerea primitives leading
to it.

> What about evaluation time? If I remember correctly, the values
> of signals depend on the time when the signal expressions are
> evaluated. So evaluating them multiple times might lead to
> different behavior. Is this correct?
It is. However, there is really only one construct that needs extra care
here: the latcher. All the others create top-level nodes that get
evaluated just once during the first attempt to sample the output of the
network. Therefore, duplication and merging of identical expressions
only affects the performance unless they are hidden in the input signal
of a latcher.

> But in contrast to ordinary values, you have an internal
> mutable state, don’t you?
Yes. But the access patterns are quite restricted, which makes things a
bit easier to reason about. I can refer to the Hume language again: it
stores state in mutable variables, but restricts each of them to have
exactly one consumer and one producer, and the movement of data is also
strictly regulated. Elerea lifts some restrictions of Hume: a variable
can have many consumers, and nodes have no obligatory delays, so a piece
of data can travel through the whole network in a single superstep. It
still seems to be tractable, but no guarantees yet.

In the end it boils down to getting the latcher to evaluate the inner
signal at the first moment too. This is easy to do with just top-level
latchers (it takes a single seq at the right place), but latchers
embedded in latchers can only be guaranteed to work if the inner signal
is not just evaluated but sampled too (an extra call to signalValue).
Which is probably what should be done anyway.

If all these precautions are taken, the resulting networks should be
equivalent with respect to superstep, which is the only way to look at
their output. Nevertheless, I'm trying to find ways to create the
network in a safer way without sacrificing flexibility on the user end.
In the meantime, I'm silently analysing the consequences of the current
design to see where and how it can break.

Gergely

-- 
http://www.fastmail.fm - One of many happy users:
  http://www.fastmail.fm/docs/quotes.html