Is FPH implemented in GHC?

[Wolfgang Jeltsch]

Am Donnerstag, 11. September 2008 00:09 schrieben Sie:
> >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..).

Hmm, maybe you misunderstood.  The extra type argument cannot be instantiated 
to the current time since that would need dependent types or something 
similar.  Actually, we never instantiate this argument but only force it to 
be independent to other such time arguments via forall, and force it to be 
equal to other such time arguments by using the same type variable multiple 
times in the same type.  So the whole thing is only about whether something 
happens at the same time or not.

It’s really similar to the first ST type argument without using RealWorld.  
You never instantiate it, you just put constraints on it in the form that it 
has to be equal to some other such argument.

> 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.).

At least, I try to help the FRP programmer to get aging etc. right by using 
the time argument trick to make wrong signal use result in a type error.  In 
Grapefruit, a signal is a function from a time *interval* to values where the 
time interval is denoted by this type argument.

> […]

> 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;-).

In Grapefruit, you could implement a continous signal which represents an 
absolute clock.  This is because you can make a continuous signal out of any 
continuous source that can be asked to tell its current value by means of an 
I/O action.  But absolute time isn’t fundamental to Grapefruit.

You could think of some totally ordered set representing time and continuous 
signals being functions from this set to values.  But you can only access 
continuous signals by sampling them using a discrete signal.  So you can only 
get the value of a continous signal at those times where some event occurs.  
You have the advantage that you can abstract from sampling rates and similar 
stuff by composing continuous signals.  But at some point you have to sample 
explicitely.

> Claus

Best wishes,
Wolfgang