tests fail with hint-0.5.0

[gelisam]

The value NoImplicitPrelude (and probably others) was removed in hint-0.5.0 for some reason?

[mvdan]

Seems like the culprit is haskell-hint/hint@b97aa88, which was just re-running the scripts to generate code with GHC 7.10. I wonder if the extension was removed in newer GHC versions? If not, I might have done something wrong or the generator program might be buggy.

[gelisam]

Looking at the diff for that commit, it looks like a bunch of new extensions were added, and that the "No" prefix was removed from all the extensions. NoImplicitPrelude definitely still works in GHC 7.10, and I can also do things like enabling and then disabling and then re-enabling an extension:

{-# LANGUAGE ImplicitParams #-}
{-# LANGUAGE NoImplicitParams #-}
{-# LANGUAGE ImplicitParams #-}

So I'm guessing that instead of having some extensions which disable some default behaviours, GHC now allows any extension to be disabled using the prefix "No", and a few of those extensions are now enabled by default.

[mvdan]

I'm not sure what the correct fix for hint is, then. Or if there's even anything to fix. In any case this seems like a regression in the library, since it breaks backwards compatibility.

Two solutions come to mind to fix the breakage:

• Manually keep a list of NoFoo extensions that used to be part of the list
• Duplicate all extensions with a No at the beginning (assuming GHC now allows this)

[gelisam]

assuming GHC now allows this

I tried compiling a file containing every single extension in your updated list and every single extension prefixed with "No". GHC 7.10.3 accepted almost everything, except those:

Generics, NoGenerics
ExtensibleRecords, NoExtensibleRecords
RestrictedTypeSynonyms, NoRestrictedTypeSynonyms
HereDocuments, NoHereDocuments
NewQualifiedOperators, NoNewQualifiedOperators
XmlSyntax, NoXmlSyntax
RegularPatterns, NoRegularPatterns
SafeImports, NoSafeImports
NoSafe
NoTrustworthy
NoUnsafe

[mvdan]

I don't understand what GHC's use of No in extensions is, then.

Also, correction on my part - I'm not getting the extensions list from the GHC APIs, but from the Cabal ones. See for example:

https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/src/Language.Haskell.Extension.html

I don't fully understand why this is being exposed by Cabal. This might also mean that the problem wasn't a newer GHC, but a newer Cabal.

[mvdan]

To clarify on the last comment, the generator program uses knownExtensions from the source linked above.

[gelisam]

I see that cabal prepends "No" a few lines below, in classifyExtension.

I there any particular reason why hint defines its own data type instead of reusing cabal's?

[mvdan]

I see that cabal prepends "No" a few lines below, in classifyExtension.

Then we're probably using this API wrong.

I there any particular reason why hint defines its own data type instead of reusing cabal's?

No idea. @jcpetruzza wrote this code, so he might be able to answer.

Daniel, I'm pinging you on a bunch of issues to ask questions on the codebase - apologies if that bothers you.

[jcpetruzza]

(@mvdan I'm happy to help)

On the question of why not re-use cabal's datatype, my motivations were: 1) avoid the extra dependency and, 2) pin a concrete version of the datatype (not cabal) to each version of hint. Otherwise, two people could be using the same version of hint and yet have different sets of extensions available, each coming from a different version of cabal.

What I think happened in this: historically ghc had some extensions whose name started with "No" (e.g. NoMonomorphismExtension, NoImplicitPrelude) and these were available in the cabal extension datatype; at some point it was decided to standardize the name of the extensions and have every extension in a positive and a negative version, hence "ImplicitPrelude" and "NoImplicitPrelude" are now accepted. I suppose then cabal decided to offer only the positive variant for consistency and hint's script that generates the extensions broke at that point.

Fixing the generator script shouldn't be hard imo

[mvdan]

Okay; then it's clear that I (unintentionally) broke backwards compatibility in Hint. Thankfully though, it was in 0.5.0 and not a minor 0.4.* release.

I'll open an issue about this.

[gelisam]

Technically, before 1.0 you're allowed to break whatever you want between any level of release. Please don't though :)

[mvdan]

Breaking backwards compatibility still sucks - especially if it's not documented :)

[gelisam]

"fixed" in #173 by disabling the tests. I'll re-enable them in #174.