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.