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

Patai Gergely patai_gergely at fastmail.fm
Thu Apr 23 12:30:51 EDT 2009

> So does this mean that whether a signal is started at the
> beginning or at switching time depends on what dependencies the
> signal has?
No, the situation is even more complicated, since some of its
dependencies might be aged through other dependency chains, while
others can only be animated through the signal in question. But
one has to make it clear what the concept of signal actually
means, see below.

> What I have in mind is the following: Say, you have a
> complicated function f :: DTime -> Bool and two signals s1 and
> s2. Then you form the following signal: (\t -> if f t then s1
> else s2) <$> time. In order to know what signals should be
> started at the beginning, you would have to know whether f will
> ever yield False or True so that you know which of s1 and s2
> will be needed at some point.
I see what you mean. Well, if a signal is not needed during
sampling, it's simply not aged by Elerea. So unless they are
referenced elsewhere, one of them will be inactive.

> Why not? You could have a signal which always yields the last
> key press. This clearly depends on the outer world. Then you
> construct another signal out of this which counts how often a
> certain key was pressed. If this latter signal is evaluated
> several times, it could start counting from different times on,
> couldn't it?
I think the concept of signal and signal transformer is getting
mixed up here. The problem with restarting is that we don't know
the boundaries. In the case of Yampa everything is clear, since
we are dealing with signal functions that have an explicit entry
and exit point. But if we're working with the signals themselves,
the inputs are not accessible any more. Considering this, what
would restarting a key count signal mean?

In the end, the question is if there is some simple
intuitive ('least surprise') semantics that fits the behaviour of
Elerea, maybe with some adjustments here and there, and what it
could possibly look like.


http://www.fastmail.fm - Same, same, but different...

More information about the Haskell-Cafe mailing list