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.