Re: [Haskell-cafe] Motion to unify all the string data types
From: Francesco Mazzoli
At Sat, 10 Nov 2012 15:16:30 +0100, Alberto G. Corona wrote:
There is a ListLike package, which does this nice abstraction. but I don't know if it is ready for and/or enough complete for serious usage. I?m thinking into using it for the same reasons.
Anyone has some experiences to share about it?
I've used it in the past and it's solid, it's been around for a while and the original author knows his Haskell.
Things I don't like:
* The classes are huge: < http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-Lis...
. I'd much rater prefer to have all those utilities functions outside the type class, for no particular reason other then the ugliness of the type class.
Speaking as the ListLike maintainer, I'd like this too. But it's difficult to do so without sacrificing performance. In some cases, sacrificing *a lot* of performance. So they have to be class members. However, there's no reason ListLike has to remain a single monolithic class. I'd prefer an API that's split up into several classes, as was done in Edison. Then 'ListLike' itself would just be a type synonym, or possibly a small type class with the appropriate superclasses. However this seems like a lot of work for relatively little payoff, which makes it a low priority for me. * It defines its own wrappers for `ByteString':
< http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-Lis...
.
The community's view on newtypes is funny. On the one hand, I see all the time the claim "Just use a newtype wrapper to write instances for ..." (e.g. the recent suggestion of 'instance Num a => Num (a,a)'. On the other, nobody actually seems to want to use these newtype wrappers. Maybe it clutters the code? I don't know. I couldn't think of a better way to implement this functionality, patches would be gratefully accepted. Anyway, you really shouldn't use these wrappers unless you're using a ByteString to represent ASCII text. Which you shouldn't be doing anyway. If you're using a ByteString to represent a sequence of bytes, you needn't ever encounter CharString.
* It doesn't have instances for `Text', you have to resort to the `listlike-instances' package.
Given that text and vector are both in the Haskell Platform, I wouldn't object to these instances being rolled into the main ListLike package. Any comments on this? John L.
At Mon, 12 Nov 2012 11:21:42 +0800, John Lato wrote:
Speaking as the ListLike maintainer, I'd like this too. But it's difficult to do so without sacrificing performance. In some cases, sacrificing *a lot* of performance. So they have to be class members.
However, there's no reason ListLike has to remain a single monolithic class. I'd prefer an API that's split up into several classes, as was done in Edison. Then 'ListLike' itself would just be a type synonym, or possibly a small type class with the appropriate superclasses.
Interesting. Are we sure that we can't convince GHC to inline the functions with enough pragmas?
However this seems like a lot of work for relatively little payoff, which makes it a low priority for me.
Fair enough.
The community's view on newtypes is funny. On the one hand, I see all the time the claim "Just use a newtype wrapper to write instances for ..." (e.g. the recent suggestion of 'instance Num a => Num (a,a)'. On the other, nobody actually seems to want to use these newtype wrappers. Maybe it clutters the code? I don't know.
I couldn't think of a better way to implement this functionality, patches would be gratefully accepted. Anyway, you really shouldn't use these wrappers unless you're using a ByteString to represent ASCII text. Which you shouldn't be doing anyway. If you're using a ByteString to represent a sequence of bytes, you needn't ever encounter CharString.
Well newtypes are good, the problem is that either you use well accepted ones (e.g. the `Sum' and `Product' in base) or otherwise it's not worth it, because people are going to unpack them and use their owns. What I would do is simply define those instances in separate modules.
Given that text and vector are both in the Haskell Platform, I wouldn't object to these instances being rolled into the main ListLike package. Any comments on this?
I think it's much better, especially for Text, since if you use ListLike you are probably using it with Text (at least in my experience). Not a big deal anyway. Francesco.
participants (2)
-
Francesco Mazzoli -
John Lato