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

[Henning Thielemann]

On Sat, 12 Jan 2013, Roman Cheplyaka wrote:

> * Henning Thielemann <lemming at henning-thielemann.de> [2013-01-12 12:40:22+0100]
>> On Sat, 12 Jan 2013, Roman Cheplyaka wrote:
>>
>> Ok, I like to request this for the whole platform. :-)
>
> This is easier to say than to do :)
>
> E.g. here's the result of a quick grep of the bytestring source code.

On compilers other than GHC, ByteString could be defined as

    newtype ByteString = ByteString (StorableVector Word8)

and StorableVector can be compiled on JHC.


> I agree that this situation is sad, but package authors are the last
> ones to blame. Instead of needlessly constraining the code we write, it
> would be much better to update the Haskell standard to reflect the
> state of modern Haskell.


It's a balance between work for library writers and work for Haskell tool 
writers. The more time library writers safe by using an extension, the 
more time Haskell tool developers have to invest in supporting those 
extensions.


> But there doesn't seem to be much interest to work on the new version of
> Haskell (see the recent thread on the haskell-prime mailing list).
>
> Thus, today H98 and H2010 serve not as something that real code should
> conform to, but rather as baselines to which extensions are applied.

If you can easily avoid using an extension, like in the case of the 
TypeSynonymInstances and FlexibleInstances in case-insensitive then this 
seems better to me, than adding FlexibleInstances to all Haskell compilers 
and Haskell tools (haddock, hlint, etc.), going through a Haskell Prime 
proposal procedure, etc.

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.