[Haskell-cafe] The Proliferation of List-Like Types

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Thu Feb 21 05:40:45 EST 2008


On Thu, 2008-02-21 at 05:07 +0100, Henning Thielemann wrote:

> As long as it is only about speeding up list processing, one might also
> consider this as optimization problem. This could be handled without
> adapting much List based code in applications to a generic sequence class.
> That is, if I convert the result of a composition of list functions to a
> lazy ByteString, I tell the compiler that I don't need full laziness and
> the compiler can optimize, say
>    ByteString.fromList . List.func1 . List.func2 . List.build
>  to
>    ByteString.func1 . ByteString.func2 . ByteString.build
>  or even better
>    ByteString.fusedFunc1Func2Build
>  by some clever fusion framework. I think that a type class is easier to
> justify if it unifies data structures that are more different than just
> providing the same API with different efficiency.

This is orthogonal I think. This could be done with stream fusion
without any common class. It requires that the types use stream fusion,
then conversions between types (eg list/array) could be done with
streams too.

Duncan



More information about the Haskell-Cafe mailing list