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

12 Jan 2013

      * Henning Thielemann  [2013-01-12 13:42:56+0100]
...
On Sat, 12 Jan 2013, Roman Cheplyaka wrote:
...
* Henning Thielemann  [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.
It doesn't make it Haskell2010, though.
...
...
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.
True. That's why I put much hope into the Haskell suite.
If your implementation's goal is to provide a different back-end, for
example, then you shouldn't need to worry about the surface syntax and
the type system. You just use available components for parsing, name
resolution, desugaring and type checking, and get most of the extensions
for free.
...
...
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 am not so sure here. That helper method or type class is just an ugly
hack to work around a limitation of the type class system.
Using it does not improve the code itself.

GHC shows that there's a way to lift this limitation (and it's been
known for many years). Is that extension controversial in the type
systems community? Why?
...
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.
I sympathise. But again, if the goal of your implementation is not to
experiment with type systems, then (in the long run) you should be able
to use the Haskell suite and not to care about these problems.

Roman