[Haskell-cafe] Fusion of lists and chunky sequences

Don Stewart dons at galois.com
Thu Jan 3 14:20:02 EST 2008


lemming:
> 
> On the one hand I like to use lists in my code because element types can
> be freely chosen and maximum laziness allows feedback and other tricks. On
> the other hand there are ByteString.Lazy and one could build chunky
> sequences from other fast array implementations. They have constraints on
> the element types like Storable in
>   http://code.haskell.org/~sjanssen/storablevector
>  and IArray multi-parameter type class for UArray.
> 
>  I like to continue writing code for lists, and let the optimizer replace
> it by operations on chunky sequences whereever possible. E.g.
>   Chunky.fromList (List.map f (List.unfoldr g x))
>  might be transformed to
>   Chunky.unfoldr (f ... g) x
> 
> Chunky.fromList serves two purposes:
>  1. I obtain the result in a data structure that can be quickly accessed
> by further operations.
>  2. It tells the optimizer that element granularity for laziness is not
> needed and that the element type fulfills the constraint of the fast array
> type, and thus fusion can go on safely. (As far as I can see.)
> 
>  Is there some framework which fuses lists and chunky sequences? When
> writing fusion rules like the above one by myself, then they interfer with
> Prelude's fusion rules (and they would probably also interfer with those
> of an alternative list fusion framework). The 'map' and 'unfoldr' is
> certainly already fused to the internal 'build' or to another auxiliary
> function. As far as I know, I cannot disable the Prelude rules and give
> the List-Chunk rules priority higher than Prelude's ones.

You can, with some caveats, use a single fusion system across data
structures, and avoid the built in build/foldr system.

I'd start by installing the stream-fusion list library, from hackage,
which gives you the list api, and a fusion mechanism.

To avoid the build in fusion system, you need to:

    * avoid list comprehensions
    * avoid .. (use Stream.enumFromTo instead)

then you can write fusion rules for your structure in terms of streams,
and they'll fuse with list operations as well.

Duncan, Roman and I plan to have strict and lazy bytestrings fusing
on top of the stream-fusion package in Q1 this year, but you can start
now looking at other data structures.

>  I hoped to be able to apply application specific fusion rules by defining
> a newtype wrapper around the chunky sequence type, while keeping the rest
> of the list code unchanged. You might argue, that code cannot be
> application specific if it still relies on the generic list type. Maybe
> it's the best to wrap the list type in a newtype and lift all of the
> application relevant list functions to this type and then define fusion
> rules on the lifted functions.

-- Don


More information about the Haskell-Cafe mailing list