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

[Peter Verswyvelen]

Oh I see. Gergely did mention it in a previous email:
Am I right thinking that the NOINLINE pragma on unsafeDupablePerformIO
prevents the problem of
multiple evaluation discussed yesterday? Or should I add NOINLINE to
primitives in Elerea.Internal too? If that guaranteed sharing, it would

So I got confused, mixing up several emails here. Mea culpa.

On Thu, Apr 16, 2009 at 12:40 PM, Lennart Augustsson <lennart at augustsson.net
> wrote:

> With NOINLINE you should be safe, but you never mentioned that originally.
> :)
>
> On Thu, Apr 16, 2009 at 10:29 AM, Peter Verswyvelen <bugfact at gmail.com>
> wrote:
> > Well, the documentation says:
> > Use {-# NOINLINE foo #-} as a pragma on any function foo that
> > calls unsafePerformIO. If the call is inlined, the I/O may be performed
> more
> > than once.
> > So you claim this does not prevent GHC to inline it anyway? That feels
> like
> > a bug then, both in the documentation and NOINLINE
> > On Thu, Apr 16, 2009 at 10:18 AM, Lennart Augustsson
> > <lennart at augustsson.net> wrote:
> >>
> >> There's no guarantee about unsafePerformIO not being inlined, that's
> >> just how ghc treats it.
> >>
> >> 2009/4/16 Patai Gergely <patai_gergely at fastmail.fm>:
> >> >> On the other hand, breaking referential transparency in the
> >> >> external interface is a very bad idea, in my opinion. Actually,
> >> >> this means that the library user would have to turn certain
> >> >> compiler optimizations off to get the intended behavior.
> >> > However, in practice you can compile Elerea with -O2 without ill
> >> > effects. In fact, that's what happens if you install it with cabal.
> >> >
> >> >> Just have a look at the Haddock docs of unsafePerformIO.
> >> > Yes, I did that too, and came up with the following checklist:
> >> >
> >> > - the order of side effects doesn't matter much, since the resulting
> >> > networks are equivalent if we don't rely on the automatic delay
> feature
> >> > (applicative optimisations can be different, but still with the same
> net
> >> > effect)
> >> > - unsafePerformIO is apparently never inlined, i.e. each instance is
> >> > executed once, so sharing works as desired
> >> > - let-floating is no problem, because all instances of unsafePerformIO
> >> > rely on surrounding function arguments
> >> > - CSE is no problem either, it even helps if it's performed (and it is
> >> > with optimisations turned on), since it results in smaller equivalent
> >> > networks
> >> >
> >> > I think we can expect it to be fairly well-behaving, because the 'side
> >> > effect' of Elerea primitives is basically the same as that of pure
> >> > values in general: upon evaluation a value is created in the memory
> and
> >> > we get a reference to it. We only have an extra constraint for the
> >> > compiler: never duplicate these values. Merging identical ones is
> okay,
> >> > and in fact desirable. The following code demonstrates this if you
> >> > compile it with and without optimisations:
> >> >
> >> > import Control.Applicative
> >> > import Control.Monad
> >> > import FRP.Elerea
> >> > import System.IO.Unsafe
> >> >
> >> > cint a b = unsafePerformIO (putStrLn "!") `seq`
> >> >           transfer 0 (\dt x x0 -> x0+x*dt) b
> >> >
> >> > mysig = (latcher 0 (b >@ 0.3) (const (cint a b) <$> cint a b)) +
> >> >        (cint a b) + (cint a b) + a
> >> >    where a = pure 4
> >> >          b = stateful 0 (+)
> >> >
> >> > main = replicateM 10 (superstep mysig 0.1) >>= print
> >> >
> >> > I'd like to see an example where optimisation does make a difference,
> >> > because I'm still unsure about the consequences of 'unsafeness'.
> >> >
> >> > Gergely
> >> >
> >> > --
> >> > http://www.fastmail.fm - Or how I learned to stop worrying and
> >> >                          love email again
> >> >
> >> > _______________________________________________
> >> > Haskell-Cafe mailing list
> >> > Haskell-Cafe at haskell.org
> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090416/95096efb/attachment.htm