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

Wolfgang Jeltsch g9ks157k at acme.softbase.org
Tue Apr 14 11:08:34 EDT 2009


Am Samstag, 11. April 2009 16:57 schrieb Patai Gergely:
> > Any idea how Elerea compares to Grapefruit? It's great to see a lot of
> > competition in the FRP arena, but I hope in the end this results in a
> > really usable and scalable FRP system for Haskell :-)
>
> I think Wolfgang can judge this better, because I don't really know the
> innards of Grapefruit,

I didn’t have a deep look at Elerea so far but looked at the Haddock docs.

If I understand correctly, Elerea’s signals construct mutable variables for 
caching their current values when they are evaluated. This happens using 
unsafePerformIO. Grapefruit’s DSignals and SSignals use a purely functional 
data structure to represent several possible future values of whom only the 
ones which are actually occuring are evaluated. This data structure is 
created using unsafeInterleaveIO.

So Elerea seems to have to take special care to not break referential 
transparency. Grapefruit has to take care only with CSignals since only these 
are using unsafePerformIO internally.

Since Grapefruit uses ordinary expression evaluation for evaluating signal 
values, it can probably make use of certain compiler optimizations. Elerea’s 
evaluation seems to be driven by hand-coded IO actions so that use of such 
compiler optimizations is certainly not possible.

Both Grapefruit and Elerea probably need a way to fix a signal to a specific 
starting time. Grapefruit does this using era type parameters. Elerea doesn’t 
seem to do anything about this at the moment.

Patai, could you please correct me where I’m wrong and clarify the points 
which are still unclear to me?

Best wishes,
Wolfgang


More information about the Haskell-Cafe mailing list