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