The future of the Haskell98 and Haskell2010 packages

Austin Seipp austin at
Tue Nov 18 16:57:59 UTC 2014

You're right, and something like that would be included. (I actually
meant GHC can still literally accept perfectly valid Haskell2010 code
in a syntactical sense; instances are part what I was referring to as
'compatible packages')

Actually, this reminds me of something SimonPJ mentioned yesterday
during this call, which may be able to fix this one bug, at least:

We could have -XHaskell2010 (or whatever it is) imply a subset of
RebindableSyntax, which only takes place for 'do' syntax. Then we
would also have the compiler import the haskell{98,2010} package as it
does today, with its own Monad (which does not have an Applicative
superclass constraint) and things would work.

This probably would not be a lot of work, but my main reservation I
suppose is that I don't think it's a very 'scalable' fix with the way
we seem to be going. If any other kind of similar change ever happened
again, we'd be stuck here once more since the same quick fix won't
apply. But if someone did the work for this, I'm not sure I would say
"no" to it.

Relatedly, I also wonder how long we should hold on to old standards.
It has been four years since a prior revision of the standard, and
almost 16 since Haskell 98. If Haskell 2015 happens soon, will we want
to have three standards packages for 7.12 if we don't remove them now?

On Tue, Nov 18, 2014 at 10:44 AM, Richard Eisenberg <eir at> wrote:
> I support this direction. But I disagree with one statement you've made:
> On Nov 18, 2014, at 11:07 AM, Austin Seipp <austin at> wrote:
>> To be clear: GHC can still typecheck, compile, and efficiently execute
>> Haskell 2010 code. It is merely the distribution of compatible
>> packages that has put us in something of a bind.
> GHC 7.10 will not be able to compile a Haskell2010-compliant Monad instance. In fact, as far as I can see, there is no way to write a Monad instance that is both portable to other Haskell compilers and acceptable to GHC 7.10. I think this point should be included in the manual (if I'm right).
> This makes me a little sad, but I don't disagree with any of the decisions we've made along the way.
> Richard


Austin Seipp, Haskell Consultant
Well-Typed LLP,

More information about the ghc-devs mailing list