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

[Patai Gergely]

> I will test it on a couple of machines, desktops and laptops.
Try using a sensible nonzero value with threadDelay. Apparently it
brings CPU usage down under Windows while retaining smoothness. However,
increasing it from zero results in jerkiness under Linux...

> If you take a look what Yampa does: it hides signals and only
> exposes signal functions. But that means that the FRP engine
> itself could indeed use mutable variables for its signals, as
> long as during the evaluation of the circuit at time T no side
> effects should occur; the side effects should take place when
> the simulation is advanced to T+dT, which is done after the
> circuit is fully evaluated at time T.
Assuming that everything works as intended, Elerea is indeed free of
side effects. As for the underlying engine, I was also considering the
Hume language, but it has an unpleasant property that every box
(analogous to the signal functions of Yampa) has an implicit delay. In
fact, Elerea can be regarded as some kind of delayless Hume if we squint
enough.

> I'm only a bit worried about your automatic insertion of
> delays; this might break referential transparency at time T,
> since it depends on the order in which the nodes in the circuit
> are evaluated no? The latter could be problematic when doing
> evaluation in parallel on multiple cores I guess.
Oh, it's problematic enough even on a single core. ;) If the network
changes at one place, it might affect evaluation order in a way that
delays can start wandering around in dependency cycles far away. It
could be interesting to analyse the effects of this behaviour. Either
way, this is just a convenience feature for applications where it makes
little difference. I was also thinking about providing two versions of
the library: one inserting delays, and another giving an error instead.

By the way, it's also in the plans to visualise the network.

Gergely

-- 
http://www.fastmail.fm - IMAP accessible web-mail