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.<div>
<br></div><div>Michael<br><br><div class="gmail_quote">On Wed, Mar 24, 2010 at 8:50 AM, John Lato <span dir="ltr"><<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I still think that getting other authors to use it would be the<br>
biggest difficulty. Another concern of mine is that RULEs-based<br>
fusion can be fragile; if the type classes prevent fusion from<br>
occurring you'll never approach the performance of monomorphic code.<br>
<br>
That said, I think this is worth pursuing further because of the<br>
benefits you describe. I have spent a great deal of time on exactly<br>
this issue with the iteratee package, although my needs there are<br>
relatively simple.<br>
<br>
As a general question to the Haskell community: have you ever<br>
attempted to write container-polymorphic code? I'd like to hear about<br>
either successes or stumbling blocks.<br>
<div><div></div><div class="h5"><br>
On Wed, Mar 24, 2010 at 12:02 PM, Alberto G. Corona <<a href="mailto:agocorona@gmail.com">agocorona@gmail.com</a>> wrote:<br>
> Once we have a tree of type classes suitable for all containers, as you<br>
> said, theoretically it shouldn't very difficult to incorporate the testing<br>
> of different instances for each class used in a program, besides testing<br>
> different compilation flags in a genetic algoritm. This latter has already<br>
> been done.<br>
> <a href="http://donsbot.wordpress.com/2010/03/01/evolving-faster-haskell-programs-now-with-" target="_blank">http://donsbot.wordpress.com/2010/03/01/evolving-faster-haskell-programs-now-with-</a><br>
> To find automatically the best combination of class implementations and<br>
> compilation flags in a single process would be very useful and would save a<br>
> lot of manual testing.<br>
><br>
> 2010/3/24 John Lato <<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>><br>
>><br>
>> Hi Alberto,<br>
>><br>
>> To some extent this already exists, it's just that nobody uses it. I<br>
>> believe it's the approach taken by the Edison libraries. Also the<br>
>> ListLike package provides the type classes ListLike, StringLike, and a<br>
>> few others. Neither seems to have become very popular despite having<br>
>> well-respected authors (Okasaki and Goerzon, respectively).<br>
>><br>
>> Some container functions are already provided by other classes, namely<br>
>> Foldable, Traversable, and Monoid.<br>
>><br>
>> The first bit, creating a tree of type classes suitable for all<br>
>> containers, is probably a few hours work.<br>
>><br>
>> An automated system to determine the best implementation is<br>
>> significantly more difficult; I can't say if the scope would be<br>
>> appropriate for SoC.<br>
>><br>
>> Best,<br>
>> John<br>
>><br>
>> > From: "Alberto G. Corona " <<a href="mailto:agocorona@gmail.com">agocorona@gmail.com</a>><br>
>> ><br>
>> > Just a dream:<br>
>> > -separate interface and implementation for all containers, via type<br>
>> > classes<br>
>> > -develop, by genetic programming techniques + quickcheck, a system that<br>
>> > find<br>
>> > the best container implementation for a particular program.<br>
>> ><br>
>> > Is that suitable for a Google Summer of Code project?<br>
>> ><br>
>> > 2010/3/23 Alberto G. Corona <<a href="mailto:agocorona@gmail.com">agocorona@gmail.com</a>><br>
>> ><br>
>> > The question can be generalized via type classes: Is there any common<br>
>> > set of<br>
>> >> primitives encapsulated into a single type class that has instances for<br>
>> >> Strings (Data.List) ByteStrings, Data.Text, Lazy bytestrings, Arrays,<br>
>> >> vectors and wathever container that can store an boxed, unboxed, packed<br>
>> >> unpacked sequence of wathever including chars? All of them have folds,<br>
>> >> heads, tails and a lot of common functions with the same name, but<br>
>> >> since<br>
>> >> there is not a single type class, the library programmer can not<br>
>> >> abstract<br>
>> >> his code when it is possible, so the library user can chose the<br>
>> >> particular<br>
>> >> instance for his particular problem.<br>
><br>
><br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>