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

bos:

you end up with a fearsome and complex set of typeclasses that are difficult to learn and follow.

And to optimize.

I have a very specific StringLike typeclass in the web-encodings package so that I can- for example- to HTML entity encoding on String, (lazy) bytestrings and (lazy) text. Of course, I need to make assumptions about character encoding for the bytestring version. Michael On Wed, Mar 24, 2010 at 8:50 AM, John Lato wrote:

I still think that getting other authors to use it would be the biggest difficulty. Another concern of mine is that RULEs-based fusion can be fragile; if the type classes prevent fusion from occurring you'll never approach the performance of monomorphic code.

That said, I think this is worth pursuing further because of the benefits you describe. I have spent a great deal of time on exactly this issue with the iteratee package, although my needs there are relatively simple.

As a general question to the Haskell community: have you ever attempted to write container-polymorphic code? I'd like to hear about either successes or stumbling blocks.

On Wed, Mar 24, 2010 at 12:02 PM, Alberto G. Corona wrote:

...

Once we have a tree of type classes suitable for all containers, as you said, theoretically it shouldn't very difficult to incorporate the testing of different instances for each class used in a program, besides testing different compilation flags in a genetic algoritm. This latter has already been done.

...

To find automatically the best combination of class implementations and compilation flags in a single process would be very useful and would save a lot of manual testing.

2010/3/24 John Lato

...

Hi Alberto,

To some extent this already exists, it's just that nobody uses it. I believe it's the approach taken by the Edison libraries. Also the ListLike package provides the type classes ListLike, StringLike, and a few others. Neither seems to have become very popular despite having well-respected authors (Okasaki and Goerzon, respectively).

Some container functions are already provided by other classes, namely Foldable, Traversable, and Monoid.

The first bit, creating a tree of type classes suitable for all containers, is probably a few hours work.

An automated system to determine the best implementation is significantly more difficult; I can't say if the scope would be appropriate for SoC.

Best, John

...

From: "Alberto G. Corona "

Just a dream: -separate interface and implementation for all containers, via type classes -develop, by genetic programming techniques + quickcheck, a system

...

...

...

find the best container implementation for a particular program.

Is that suitable for a Google Summer of Code project?

2010/3/23 Alberto G. Corona

The question can be generalized via type classes: Is there any common set of

...

primitives encapsulated into a single type class that has instances for Strings (Data.List) ByteStrings, Data.Text, Lazy bytestrings, Arrays, vectors and wathever container that can store an boxed, unboxed,

http://donsbot.wordpress.com/2010/03/01/evolving-faster-haskell-programs-now... that packed

...

...

...

...

unpacked sequence of wathever including chars? All of them have folds, heads, tails and a lot of common functions with the same name, but since there is not a single type class, the library programmer can not abstract his code when it is possible, so the library user can chose the particular instance for his particular problem.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe