Is FPH implemented in GHC?
g9ks157k at acme.softbase.org
Thu Sep 11 07:58:32 EDT 2008
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
More information about the Glasgow-haskell-users