[Haskell-cafe] ANN: Elerea, another FRP library
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?
More information about the Haskell-Cafe