Fwd: [Haskell-cafe] Bytestrings and [Char]

Alberto G. Corona agocorona at gmail.com
Wed Mar 24 18:34:12 EDT 2010

---------- Forwarded message ----------
From: Alberto G. Corona <agocorona at gmail.com>
Date: 2010/3/24
Subject: Re: [Haskell-cafe] Bytestrings and [Char]
To: Stephen Tetley <stephen.tetley at gmail.com>

2010/3/24 Stephen Tetley <stephen.tetley at gmail.com>

Hi Alberto
> I rather doubt a valuable set of type classes that is suitable for all
> containers exists, I'm afraid.
> If you consider containers as the containers package, the data
> structures are all (?) functorial  - but they have different shapes,
> so e.g. a cons operation makes sense on the linear ones
> (Data.Sequence, Data.List) but not on Data.Map, Data.Tree. 'cons' is
> analogous to 'insert' but 'insert' exactly describes the operation on
> maps whereas 'cons' doesn't, similarly 'insert' doesn't describe the
> 'cons' operation on lists exactly as it doesn't indicate the position
> of where it adds to the list.

Some operations like insert in list could be inefficient, some operations
like cons in maps could be an inefficient hack, but at this does not means
that a list can do  create, insert,  map , lookup faster that a Map in the
case of sort lists, for example. A generalized cons applied to a Map can
make less sense, but a program made for lists with occasional cons's can
happen to perform better with Maps and so on.  So a library with generality
in mind can perform optimally in two or more different scenarios with
different instances/implementations.  . A genetic algoritm can have the
opportunity to detect this.

 I think also that a complex list of class hierarchies is neither necessary
nor recommended. We are not talking about mathemathical concepts. This is a
performance issue.

Even if a definitive class hierarchy is a problem, hopefully it may be worth
to define tentative and temporal classes for performance testing purposes,
that warps the common primitives with the sole purpose of executing the
testing algorithm for different instance implementations, compilation flags
and fusion rules.

> Now, if you partition the type classes into small groups you get over
> the fact that some operations make sense on certain 'shapes' of data
> structure, but there are still subtle type differences that aren't
> conducive to type classes - e.g. ByteString and Data.Text aren't
> functorial so map is type restricted:
> map  :: (Word8  -> Word8) -> ByteString  -> ByteString
For this purpose,  specific testing classes for Word8 data -with no claim to
be "official" can be defined by the programmer, leaving to the library user
to run the testing process for the different instances in his particular

I know that this add extra work and that not many would do this extra level
of abstraction, but perhaps this is less work than spending even more time
exchanging emails, discussing low level issues, performing tests, trying to
figure out what will be the most common sceniarios for wich the library
could be used, testing manually what is the container that has the most
performance here and now, not tomorrow for these scenarios, to worry about
the obsolescence of the library for reasons not related with the library
algorithm  etc

Also, while ListLike does provide default definitions for many ops I'm
> guessing its more important for performance to redefine them, so the
> defaults definitions aren't adding much.
> There might be a couple of useful new type classes waiting in the
> wings, e.g a destroy one as per view in Data.Sequence, but I doubt
> that a proliferation of classes will generally make programs clearer
> or more efficient and it would introduce more instances of problems
> that we already have with Num type class.
> class Destroy f where
>  destroy :: f a -> (a, Maybe (f a))
> Best wishes
> Stephen
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100324/99212178/attachment.html

More information about the Haskell-Cafe mailing list