I think this is an interesting question: is GHC2021 something that will, for example, just start appearing in a default cabal/stack file? Or, is it the long-awaited -XKitchenSink that I can just enable (explicitly) to imply this common/convenient set of extensions? If the former, I definitely agree - perhaps it’s not a good move. If the latter, these older tutorials/blogs won’t break because they won’t recommend turning on the extension. It’s also worth pointing out that the error is actually very good here:
:set -XNoStarIsType :kind *
<interactive>:1:1: error:
Operator applied to too few arguments: *
With NoStarIsType, ‘*’ is treated as a regular type operator.
Did you mean to use ‘Type’ from Data.Kind instead?
Ultimately, though, if this extension is going to become a default in our tools rather than something that is opt-in, I absolutely agree - best not to break a wealth of resources for the sake of one extra line in my default-extensions list.
Cheers,
Tom
On 4 Dec 2020, at 11:14, Alejandro Serrano Mena
Right, we better be clear about ForeignFunctionInterface. Those who voted ForeignFunctionInterface: no, do you *really* want to turn off an extension that's already part of the Haskell standard?
In fact, the following extensions are implied by Haskell2010: ImplicitPrelude StarIsType CUSKs MonomorphismRestriction DatatypeContexts TraditionalRecordSyntax EmptyDataDecls ForeignFunctionInterface PatternGuards DoAndIfThenElse RelaxedPolyRec And the following non-Haskell2010 extensions are on by default (but not in Haskell2010 mode): NondecreasingIndentation NoDatatypeContexts I should have written the ballot consistently relative to Haskell2010, it’s a mixed bag right now, inherited from the survey. Or should it be relative to the GHC’s unnamed “default mode” (which is neither Haskell98 nor Haskell2010)? Anyways, one goal for GHC2021 is that it will subsume this unnamed default mode. So let’s see: Interesting ones: StarIsType -- ^ 5 votes. Those who voted no, did you do that knowing that it’s on by default these days? CUSKs -- ^ Legacy feature according to the docs, but the replacement StandaloneKindSignatures only has 50% votes so far. We probably need exactly one of the two. Both are new 8.10. MonomorphismRestriction -- ^ 4 votes. Those who voted no, did you do that knowing that it’s part of Haskell2010? (I admit I didn’t) ForeignFunctionInterface -- ^ 4 votes. Those who voted no, did you do that knowing that it’s part of Haskell2010? NondecreasingIndentation -- ^ Currently on by default, but off in Haskell2010 2 votes. Docs at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#co... Do we really want to turn it off? There must have been a good reason for GHC to have different default behavior so far? Boring ones: ImplicitPrelude -- ^ Obviously stays DatatypeContexts -- ^ 0 votes. This goes away. Yay! TraditionalRecordSyntax -- ^ NoTraditionalRecordSyntax has zero votes, so can stay EmptyDataDecls -- ^ 10 votes, so can stay PatternGuards -- ^ NoPatternGuards has zero votes, so can stay DoAndIfThenElse -- ^ wasn’t even on the ballot, probably a consequence of https://gitlab.haskell.org/ghc/ghc/-/issues/18631 I assume this stays unless someone disagrees. RelaxedPolyRec -- ^ Impossible to turn off, so this stays. Sorry for the confusion, next time round will be easier, when there is a clear base line (i.e. GHC2021). Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee