Haskell Platform proposal: Add case-insensitive and Haskell 98/2010 compliance

Ben Millwood haskell at benmachine.co.uk
Mon Jan 14 17:31:38 CET 2013

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 
>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.

More information about the Libraries mailing list