In my experience, it is usually a more pragmatic solution to pick the
string type that is most suitable for the library's purposes, and leave
conversions to the consumer.
In practice, the choice is typically between strict and lazy Text only:
bytestrings do not represent strings but byte arrays, so they are not
suitable for textual data; and String has atrocious performance, unless the
use case is just linear character-wise traversal (and even then, lazy Texts
are probably still a better choice). I would only choose String if my
library were closely related to another library that has already picked
String, and converting to and from Text would introduce a lot of overhead.
The downside of making your API polymorphic is that you will often find
yourself having to type-annotate to disambiguate (foo . (bar :: Int ->
Text) $ n), or introduce type-binding dummy functions (foo . asText . bar $
n). Another downside is that there is no canonical "StringLike" typeclass,
so you either have to write your own, or pick one as a dependency. That
said, there are a few libraries out there that aim to make the Haskell
string situation less painful, including my own string-convert. They all
differ in a few details, it mostly comes down to preference.
On Jul 14, 2016 3:00 AM, "Edward Z. Yang"
Hello KwangYul,
Supporting this sort of parametricity is one of the goals of the Backpack project. You can see some code that demonstrates how this might be done: https://github.com/yihuang/tagstream-conduit/pull/18 Maybe you'll get to use this feature in GHC 8.2!
A big problem with StringLike type classes is that you must pre-commit to the set of operations which are supported before hand. For strings, there are many, many such operations, and it is difficult to agree a priori what these operations should be.
Edward
Hi all,
There are multiple string types in Haskell – String, lazy/strict ByteString, lazy/strict Text to name a few. So to make a string handling function maximally reusable, it needs to support multiple string types.
One approach used by TagSoup library is to make a type class StringLike which represents the polymorphic string type and uses it where a String type is normally needed. For example,
parseTags :: StringLike str => str -> [Tag str]
Here parseTags takes a StringLike type instead of a fixed string type. Users of TagSoup can pick any of String, lazy/strict ByteString, lazy/strict Text because they are all instances of StringLike type class.
It seems StringLike type class is quite generic but it is used only in
Excerpts from KwangYul Seo's message of 2016-07-13 17:40:13 -0700: the
TagSoup package. This makes me wonder what is the idiomatic way to support multiple string types in Haskell. What other approaches do we have?
Thanks, Kwang Yul Seo
Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.