Is FPH implemented in GHC?

[Claus Reinke]

>If an FRP library provides first-class signals then often the problem arises
>that these are actually signal generators—their behavior might depend on the
>time they are started.  To get rid of this deficiency, my signal types now
>have an additional type argument which denotes the starting time.  This way,
>I’m able to fix the starting time using the type system.  The idea is similar
>to the usage of the “state” type argument of ST.

Dependencies on an absolute clock always caused trouble in
Fran/FRP programming and were one of the things I tried to get
rid of in my FunWorlds experiments (sigh, way too long ago..).

Thinking of behaviours as functions from *all* times to values is
an unimplementable theoretical ideal and completely at odds with
FRP's more practical ideal of compositional programming (leading
to the less sung about "arts" of actual programming in FRP, aging
behaviours, start times, etc.).

Thinking of behaviours as something one can do measurements
on, yielding current value and residual behaviour, leads to simpler
semantics, implementation and programming. If you want a (local!)
clock, just integrate over a constant.

Many of the FunWorlds aspects would need revision, if I ever
get round to that.. but dropping absolute time was the right thing
to do (as if physics hadn't told us about that anyway;-).

Claus