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

[Patai Gergely]

> I wonder if this breaks referential transparency. Say, you define a signal
> s and use s twice in some expression. s may be evaluated once and it
> maybe evaluated twice. Does this make a difference?
I'm not sure about the answer at the moment, but I believe we'd simply
get two identically behaving signals in most cases, assuming they are
evaluated in the same superstep. The automatic insertion of delays into
cycles might cause problems here, as it depends on the current topology
of the dataflow network what exactly happens. However, if all the cycles
are broken with explicit delays, this is not an issue any more. It would
break everything if IO-fed signals were created multiple times, but that
can't happen, since their construction is explicitly marked by IO.

> Is it possible that thereby the second “instance” has different values
> than the first one?
I can't exclude the possibility, unfortunately, especially with the
delay magic. But this is a question that needs further investigation.

> When are your signals started? At evaluation time?
Yes. Evaluation returns an IORef holding the initial state of the
signal, wrapped in some structure. The top-level network is traversed at
the beginning, so its nodes are all evaluated just once.

> If yes, doesn’t this mean that the meaning of a signal depends on
> evaluation time so that evaluating the same signal expression twice
> actually results in two different signals?
That's exactly the case. The system heavily relies on sharing in order
to work properly. In fact, the ability to keep track of sharing under a
pure-looking interface was the main motivation to choose this particular
implementation. As far as I can tell, it should be fine as long as no
Elerea primitive (signal constructors defined in Internal) is inlined.
But I don't like this either, and I'd love to hear how the same effect
can be achieved without resorting to such fragile constructs.
Unfortunately, all my previous attempts failed at one point or
another...

> So Elerea seems to have to take special care to not break
> referential transparency.
No matter how I look at it, that would make it a completely different
library. One that's very close to Reactive, in fact.

> Elerea’s evaluation seems to be driven by hand-coded IO actions
> so that use of such compiler optimizations is certainly not possible.
This is quite true. On the other hand, most calculation is happening in
pure functions anyway, and reactive book-keeping probably constitutes
only a small fragment of the runtime in a typical application, so this
is less of a worry for me. In the end, I see FRP as an alternative way
to manage entities, and entities surely can't be optimised away. I use
applicative laws to unite pure parts as much as possible, although I
don't expect the resulting functions to be as efficient as if they had
been assembled at compile time. A JIT compiler surely wouldn't hurt. :)

> Grapefruit does this using era type parameters. Elerea doesn’t 
> seem to do anything about this at the moment.
Apart from counting on conditions mentioned above, no. The intended
meaning is that new signals are created whenever a latcher asks for one,
but there's no way to enforce that for the time being.

> Patai, could you please correct me where I’m wrong and clarify the
> points which are still unclear to me?
It seems I can hardly say anything new, because you see all the issues
perfectly. (By the way, Patai is my family name. Different endianness
over here. ;)

> What do you think, Grapefruit is lacking, compared to Reactive?
Oh, it's just my subjective opinion that I find the interface of
Reactive very easy to use and flexible. That's primarily what I wanted
to replicate in Elerea, I just ended up getting rid of events
altogether, as I didn't need them, and that gave me a simpler system to
play with. Grapefruit looks like something that feels more natural when
describing the system at a higher level. But I really need to play with
it more to have a well-founded opinion.

Gergely

-- 
http://www.fastmail.fm - mmm... Fastmail...