[Haskell-cafe] Re: optimization help

[apfelmus at quantentunnel.de]

Paul Hudak wrote:
> In fact avoiding space leaks was one of the motivations for our moving
> to an arrow framework for FRP (now called Yampa).  Arrows amount to a
> point-free coding style, although with "arrow syntax" the cumbersomeness
> of programming in that style is largely alleviated.

I think that's an entirely different thing.

You changed representation of signal transformers from

    newtype SF a b = SF ([a] -> [b])

to

    data SF a b = SF (a -> (b, SF a b))

By enforcing a synchronous processing, you avoid leaking Signals. The
latter cannot be isomorphic to a function type (Signal a -> Signal b)
for an appropriate Signal, so this implies a point-free style as there
is no way to hold stuff of type (Signal a) in variable bindings.

This does not mean that there is no point-wise syntax for arrows, it
just means that point-wiseness cannot be achieved via variables in the
context of function application, i.e. via lambda abstraction. In fact,
the main point about Arrows is not that they are an abstraction for
computations but that they allow a point-wise syntactic sugar (which
stems from their computational being, of course)!


The optimization problem here uses (almost) one and the same
representation (pure (a -> b), sometimes packed in (a -> IO b)) and
point-free turns out to be space friendlier than point-wise. That's very
puzzling and i think ghc -O2 should eliminate this.


Regards,
afpelmus



PS: IMHO the semantics of (SF a b) need a real cleanup. (Time -> a) ->
(Time -> b) is too crude, because these map transformers even cannot be
made an instance of ArrowChoice. Also, Dirac-like peaks (that is Events)
do not fit in.