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

Henning Thielemann lemming at henning-thielemann.de
Thu Feb 21 07:34:00 EST 2008


On Thu, 21 Feb 2008, Duncan Coutts wrote:

> 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.

I suppose we mean the same. My question is: Why do we use ByteString
instead of [Word8] ? Entirely because of efficiency, right? So if we could
stick to List code and only convert to ByteString at the end and the
compiler all rewrites it to ByteString code, then we would not need
libraries that are specialised to ByteString, but they can use [Word8]
instead.


More information about the Haskell-Cafe mailing list