Hi, In MissingH, I have a bunch of little functions that operate on lists. Some, like uniq (which eliminates duplicate elements in a list), operate on (Eq a => [a]) lists. Others, like strip (which eliminates whitespace at the start and end), operate on Strings only. Most functions of both types would be useful on ByteStrings and lazy ByteStrings. Most of these functions are written in terms of Data.List functions or list primitives that have equivolents in Data.ByteString. So, my question is: is there a clever hack available to me so that I could have 1 version of each function, and have it work on all three different types of input? I'd rather avoid having 3 versions, that are exactly the same except for imports. Thanks, -- John
On Wed, 2006-07-05 at 05:58 -0500, John Goerzen wrote:
Hi,
In MissingH, I have a bunch of little functions that operate on lists. Some, like uniq (which eliminates duplicate elements in a list), operate on (Eq a => [a]) lists. Others, like strip (which eliminates whitespace at the start and end), operate on Strings only.
Most functions of both types would be useful on ByteStrings and lazy ByteStrings. Most of these functions are written in terms of Data.List functions or list primitives that have equivolents in Data.ByteString.
So, my question is: is there a clever hack available to me so that I could have 1 version of each function, and have it work on all three different types of input? I'd rather avoid having 3 versions, that are exactly the same except for imports.
People sometimes talk about doing a type class to cover string like modules. What functions are you thinking of btw? We may want to include them in the ByteString modules anyway (possibly directly rather than in terms of other functions, to take advantage of tricks with the representation). Duncan
duncan.coutts:
On Wed, 2006-07-05 at 05:58 -0500, John Goerzen wrote:
Hi,
In MissingH, I have a bunch of little functions that operate on lists. Some, like uniq (which eliminates duplicate elements in a list), operate on (Eq a => [a]) lists. Others, like strip (which eliminates whitespace at the start and end), operate on Strings only.
Most functions of both types would be useful on ByteStrings and lazy ByteStrings. Most of these functions are written in terms of Data.List functions or list primitives that have equivolents in Data.ByteString.
So, my question is: is there a clever hack available to me so that I could have 1 version of each function, and have it work on all three different types of input? I'd rather avoid having 3 versions, that are exactly the same except for imports.
People sometimes talk about doing a type class to cover string like modules.
What functions are you thinking of btw? We may want to include them in the ByteString modules anyway (possibly directly rather than in terms of other functions, to take advantage of tricks with the representation).
Spencer Janssen is actually working on such a class (String) to deal with this, initially to support [a] and Word8 and Unicode bytestrings, as part of his Summer of Code project. Note also that we have the Foldable and Monoid classes, which support parts of a String interface. -- Don
Hello Donald, Wednesday, July 5, 2006, 3:38:44 PM, you wrote:
In MissingH, I have a bunch of little functions that operate on lists. Some, like uniq (which eliminates duplicate elements in a list), operate on (Eq a => [a]) lists. Others, like strip (which eliminates whitespace at the start and end), operate on Strings only.
Spencer Janssen is actually working on such a class (String) to deal with this, initially to support [a] and Word8 and Unicode bytestrings, as part of his Summer of Code project.
it will be better to implement ListLike class that supports any type of elements -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Wed, Jul 05, 2006 at 09:38:44PM +1000, Donald Bruce Stewart wrote:
What functions are you thinking of btw? We may want to include them in the ByteString modules anyway (possibly directly rather than in terms of other functions, to take advantage of tricks with the representation).
Spencer Janssen is actually working on such a class (String) to deal with this, initially to support [a] and Word8 and Unicode bytestrings, as part of his Summer of Code project.
That's nice, but that sounds different. I'm specifically wanting support for the ByteString and lazy ByteString types. Also, it sounds like he would have to re-implement some of the functions you already have in ByteString.
Note also that we have the Foldable and Monoid classes, which support parts of a String interface.
Hello Duncan, Wednesday, July 5, 2006, 3:25:53 PM, you wrote:
People sometimes talk about doing a type class to cover string like modules.
class ListLike ce e | ce->e where head :: ce -> e .... instance ListLike [a] a .... instance ListLike (Sequence a) a .... instance ListLike ByteString Char .... instance ListLike (ArraySlice a) a .... (ByteString is really array slice specialized for "StorableArray Char")
What functions are you thinking of btw? We may want to include them in the ByteString modules anyway (possibly directly rather than in terms of other functions, to take advantage of tricks with the representation).
we anyway need class to allow implementing, say, FilePath module working with strings of any type -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Wed, Jul 05, 2006 at 12:25:53PM +0100, Duncan Coutts wrote:
different types of input? I'd rather avoid having 3 versions, that are exactly the same except for imports.
People sometimes talk about doing a type class to cover string like modules.
Yes, that makes sense to me. I was sorta hoping to avoid having to say something like: instance StringLike B.ByteString where vlength = B.length vcons = B.cons ... with about 50 of these lines ...
What functions are you thinking of btw? We may want to include them in the ByteString modules anyway (possibly directly rather than in terms of other functions, to take advantage of tricks with the representation).
Most everything here: http://quux.org/devel/missingh/html/MissingH-Str.html The appropriate bits from: http://quux.org/devel/missingh/html/MissingH-List.html And perhaps even: http://quux.org/devel/missingh/html/MissingH-Str-CSV.html Also, it would be nice to see direct regexp support in ByteString. It seems ugly to have to convert to a String just to pass it back to C. But even if you did implement all of that, I think there is still utility in having a generic typeclass that can take any of the three string-like types that we have in Haskell these days. Otherwise, you are going to see library fracturization -- some code works with Strings, some with ByteStrings, some with lazy ByteStrings, and woe to the programmer that has to integrate all this mess. (OCaml has this problem in a big way with its lists vs. Streams and built-in handicapped IO vs. Posix IO) -- John
participants (4)
-
Bulat Ziganshin -
dons＠cse.unsw.edu.au -
Duncan Coutts -
John Goerzen