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

[Patai Gergely]

> > network. Therefore, duplication and merging of identical
> > expressions only affects the performance unless they are
> > hidden in the input signal of a latcher.
> 
> But isn't the latter a fundamental problem?
Of course it is, but I said afterwards that this can be resolved by
sampling 'more thoroughly'.

> If the time signal is evaluated only once then for any signal
> c, timeSwitching c should be equivalent to time. But what if I
> replace time by stateful 0 (+) in the definition of
> timeSwitching? If stateful 0 (+) is evaluated everytime a
> switch occurs then timeSwitching would always switch back to
> time 0.
The value stored in a constant signal is supposed to be evaluated
exactly once, therefore in this case the expected behaviour is that
timeSwitching is equivalent to time. The meaning of 'pure sig' is a
signal that refers to 'sig' at every point. At the present moment, if
you express the same by lifting the signal constructor directly, it will
also be evaluated exactly once, but only when the control signal is true
for the first time. This is obviously wrong, but it can be cured by
forcing evaluation at the beginning.

This also means that if you want to restart a signal without external
dependencies using a latcher, you have to inject some bogus dependency
to prevent memoisation. If the new signal depends on some others,
latching should behave intuitively.

> So one first has to answer the question what the intended
> semantics should be.  Should signals start at the beginning or
> should they start every time they are switched into?
Clearing up the semantics is certainly on my todo list. :)

> Implementing the first semantics is difficult since the system
> would have to know what signals will be used later. I think
> this is impossible in general because of undecidability
> issues. (Grapefruit's approach is to force the user to specify
> what signals are used later.)
Do you have a compact use case that demonstrates this problem?

> Implementing the second semantics would require a single signal
> having possibly different values when started at different
> times. This in turn would disallow caching of signal values in
> mutable variables.
Or at least it would require deep copying some initial snapshot at every
restart. But this only applies to completely self-contained signals,
since anything that depends on the outer world cannot be restarted by
definition.

Gergely

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
                          unladen european swallow