[Haskell-cafe] Bytestrings and [Char]

[Michael Snoyman]

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 <jwlato at gmail.com> 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 <agocorona at gmail.com>
> 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.
> >
> http://donsbot.wordpress.com/2010/03/01/evolving-faster-haskell-programs-now-with-
> > 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 <jwlato at gmail.com>
> >>
> >> 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 " <agocorona at gmail.com>
> >> >
> >> > Just a dream:
> >> > -separate interface and implementation for all containers, via type
> >> > classes
> >> > -develop, by genetic programming techniques + quickcheck, a system
> that
> >> > 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 <agocorona at gmail.com>
> >> >
> >> > 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,
> 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 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/d770a9d6/attachment.html