I think that the Haskell Platform should respond to genuine, rather than theoretical, demand for portability. At the moment it looks like portability is work that no-one would actually benefit from. I don't think other compilers are not forthcoming because GHC dominates the ecosystem. I think GHC dominates the ecosystem because other compilers are not forthcoming. If people who are really developing an alternative compiler come forward and say, "I would like this package to work with my compiler", I say that's worth listening to. If we only hear theorising about the existence of such people, I don't think we should lose any sleep over it. So, Henning, you are the only person so far who has presented a possible concrete need: On Sat, Jan 12, 2013 at 01:42:56PM +0100, Henning Thielemann wrote:
I also speak in a self-interest: We are developing a kind of Haskell interpreter for the live-sequencer: http://www.youtube.com/watch?v=sXywCHR9WwE
We are far from a complete Haskell 98 implementation and I am not keen on implementing extensions that are not really needed and it seems that the Haskell prime committee also does not have time for it.
So even if not all packages in the platform are Haskell 2010, I would prefer that case-insensitive is Haskell 2010 for better portability, like the split package was successfully converted to Haskell 2010 for inclusion in the platform.
In response to this, I ask you: is compatibility with the platform really a goal for your live-sequencer? Would the live-sequencer benefit particularly from use of the case-insensitive package? Would making the case-insensitive package Haskell2010 enable it to work with your interpreter immediately? If the answer to any of those questions are no, I think portability work now is premature. If the real demand arises, we can always make the alterations necessary in a future version. --- That all said, I do have my own concerns with case-insensitive. Particularly, it provides an instance FoldCase ByteString, implicitly treating ByteStrings as text, which I believe should be discouraged. This is easily fixed, although may be controversial: remove the ByteString instances. This would perhaps be slightly less painful if there was something along the lines of: mkWith :: (s -> s) -> s -> CI s mkWith fc s = CI s (fc s) so that people insistent on using ByteString would be able to do so without risking orphan instances. However, the existence of the above function allows "unsafe" use, comparing values constructed with incompatible case-folding functions, which is probably a bad idea – perhaps ByteString people should stick to newtypes instead.