Haskell Platform proposal: Add case-insensitive and Haskell 98/2010 compliance
Roman Cheplyaka
roma at ro-che.info
Sat Jan 12 14:39:10 CET 2013
* Henning Thielemann <lemming at henning-thielemann.de> [2013-01-12 13:42:56+0100]
>
> 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.
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
More information about the Libraries
mailing list