[Haskell-cafe] Mime / Mail library

[John Lato]

> From: Christopher Done <chrisdone at googlemail.com>
>
> On 20 March 2011 15:05, Pieter Laeremans <pieter at laeremans.org> wrote:
>
> > Hi all,
> >
> > The MIME package that can be found on hackage, uses String as input.
> > Would i be considered better if there would be a version based on Text,
> or
> > ByteString ?
> >
>
> I think the solution to this problem is a generic `string' package which
> just provides a few classes. The MIME library would export an interface
> that
> only deals with instances of these classes, and whether you're using Text,
> String, ByteString/Lazy/Char8, ropes, whatever, it's not the library
> writer's concern or assumptions to make.
>
> We already have:
>
> http://hackage.haskell.org/packages/archive/string-combinators/0.6/doc/html/Data-String-Combinators.html
> <
> http://hackage.haskell.org/packages/archive/string-combinators/0.6/doc/html/Data-String-Combinators.html
> >
> Which works on Monoid and IsString, but there needs to be a class like "can
> be read/outputted via IO" and one for read/show/serialize, both of which
> are
> important for speed.
>
> Anyone already done work on this? The Data.ByteString modules could export
> some instances. It's fair enough that people who need fine-grained speed
> use
> the concrete types and all their special-purposes functions, but in the
> general having to choose arbitrarily (often defaulting to String) is a
> burden. Can't we standardize on a default set of String classes to use?
>
> I suppose I could try reducing Data.ByteString's function set into a set of
> essential core methods, seeing as the ByteString modules are a very good
> spec of what's required for a String type to be completely usable.
>

Data.ListLike (http://hackage.haskell.org/package/ListLike) provides this
via the "StringLike" class (and StringLikeIO).  There are built-in instances
for Strings and ByteStrings, with orphan Text instances in
http://hackage.haskell.org/package/listlike-instances.

Probably the StringLike class could be extended to provide more
(high-performance) methods, but I don't have a good idea of what's
necessary.  Suggestions are welcome!

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110321/ab8d2c50/attachment.htm>