[Haskell-cafe] Lazy cons, Stream-Fusion style?

[Henning Thielemann]

On Sun, 2 Jan 2011, Stephen Tetley wrote:

> Un-optimized, with a head-strict stream (basically Wouter Swierstra's
> Stream with a bang on the element), rendering currently takes minutes
> to generate seconds. But as well as the Stream representation, I've
> plenty of room to optimize the WAV file generation.

Using stream-fusion:Stream rendered to a low-level list representation you 
get relatively efficient computation. I used my signal generator type and 
StorableVector.Lazy in order to perform this one in real-time:
   http://www.youtube.com/watch?v=KA6DE9jlpSY

(see packages synthesizer-core and synthesizer-alsa)

That is, even interactive realtime processing is possible, but not very 
complex one. It requires very disciplined programming and after a small 
change to your program the GHC optimizer may decide to compile it 
completely different and the program becomes five times slower.

I have also written an overview of what data structures are useful for 
what signal processing purpose:
   http://hackage.haskell.org/packages/archive/synthesizer/0.2.0.1/doc/html/Synthesizer-Storage.html

> Probably I can live without definitions like @ ones = 1 <:> ones @, I
> would like to know whether of not this is impossible with
> Stream-Fusion anyway.

The recursive style allows for elegant writing of feedback, solution of 
differential (e.g. oscillation) equations. It's sad, but I think you 
cannot have it with stream-fusion. Maybe in future GHC or JHC get more 
cleverness to eliminate even more lazy values. For feedback with longer 
and constant delay, you might buffer the data in a chunky storable vector 
and then get efficient recursive computation.