Re: [Haskell-cafe] Mime / Mail library

[Mario Blažević]

On Sun, Mar 20, 2011 at 10:50 AM, Christopher Done  wrote:

> On 20 March 2011 15:05, Pieter Laeremans  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
> 
> 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.
>
>

One possible extension to the Data-String-Combinators approach can be found
in my new incremental-parser package (
http://hackage.haskell.org/package/incremental-parser-0.1), which I should
soon announce. It relies on three Data.Monoid subclasses, all plain Haskell
98, that allow monoids to be decomposed and parsed. There are instances for
lists, ByteString, and Text. It's a different approach from ListLike,
because it abstracts away the Char type.

Like with any abstraction, though, there is performance cost for some
operations. It could be minimized by adding more defaulted methods to the
FactorialMonoid class, but for the first release I concentrated on what the
parser needed.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Mime / Mail library

[John Lato]

> From: Christopher Done 
>
> On 20 March 2011 15:05, Pieter Laeremans  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.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Mime / Mail library

[Michael Snoyman]

You might consider looking at mime-mail[1] instead, which uses a
combination of String and ByteString as appropriate. I will likely
change it to use Text in place of String in the not-too-distant
future.

Michael

[1] http://hackage.haskell.org/package/mime-mail

On Sun, Mar 20, 2011 at 4:05 PM, Pieter Laeremans  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 ?
> kind regards,
> Pieter
>
>
>
> --
> Pieter Laeremans 
>
> "The future is here. It's just not evenly distributed yet."  W. Gibson
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

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

Re: [Haskell-cafe] Mime / Mail library

[Christopher Done]

On 20 March 2011 15:05, Pieter Laeremans  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

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.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Mime / Mail library

[Pieter Laeremans]

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 ?

kind regards,

Pieter




-- 
Pieter Laeremans 

"The future is here. It's just not evenly distributed yet."  W. Gibson
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe