<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
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:
<div class=""><br class="">
</div>
<div class="">
<div class="">> :set -XNoStarIsType</div>
<div class="">> :kind *</div>
<div class=""><br class="">
</div>
<div class=""><interactive>:1:1: error:</div>
<div class="">    Operator applied to too few arguments: *</div>
<div class="">    With NoStarIsType, ‘*’ is treated as a regular type operator.</div>
<div class="">    Did you mean to use ‘Type’ from Data.Kind instead?</div>
<div class=""><br class="">
</div>
<div class="">Ultimately, though, if this extension <i class="">is</i> 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.</div>
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">Tom</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 4 Dec 2020, at 11:14, Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com" class="">trupill@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div dir="ltr" class="">In this case I think we should be a bit more conservative. There’s abundant documentation using “*” as the kind of ground types (people would often say “Maybe is a constructor of kind star to star”). We have to remember that we aim for
 GHC2021 to be the default language people use, so making a lot of information about Haskell obsolete seems like a very dangerous step here. As far as I know, the other extensions we have chosen just extend the language, but do not invalidate anything.</div>
<div dir="ltr" class=""><br class="">
</div>
<div dir="ltr" class="">Regards,</div>
<div dir="ltr" class="">Alejandro</div>
<div dir="ltr" class=""><br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 4 Dec 2020 at 12:07:33, Tom Harding <<a href="mailto:tomjharding@live.co.uk" class="">tomjharding@live.co.uk</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">I can offer an answer RE StarIsType. While I know it’s currently the default, my understanding was that NoStarIsType was introduced as one of a series of steps to deprecate/discourage the use of * as something other than a regular binary operator.
 Given that, and the fact that GHC2021 is an extension I’d enable like any other (right?), I don’t think it’s necessarily a problem to include NoStarIsType. After all, the introduction of this extension won’t break any existing code (because it won’t be enabled)
 and it’s probably best to steer people (very gently) away from * ~ Type.<br class="">
<br class="">
This decision obviously hinges on a couple of assumptions, and maybe this is a controversial opinion, but I don’t think it’s necessarily a bad thing to include this, even though it disagrees with the Haskell2010 spec.<br class="">
<br class="">
Thanks,<br class="">
Tom<br class="">
<br class="">
<blockquote type="cite" class="">On 4 Dec 2020, at 10:57, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a>> wrote:<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">Hi,<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">Am Freitag, den 04.12.2020, 09:57 +0000 schrieb Simon Marlow:<br class="">
</blockquote>
<blockquote type="cite" class="">> Right, we better be clear about ForeignFunctionInterface. Those who<br class="">
</blockquote>
<blockquote type="cite" class="">> voted ForeignFunctionInterface: no, do you *really* want to turn off<br class="">
</blockquote>
<blockquote type="cite" class="">> an extension that's already part of the Haskell standard?<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">In fact, the following extensions are implied by Haskell2010:<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">   ImplicitPrelude<br class="">
</blockquote>
<blockquote type="cite" class="">   StarIsType<br class="">
</blockquote>
<blockquote type="cite" class="">   CUSKs<br class="">
</blockquote>
<blockquote type="cite" class="">   MonomorphismRestriction<br class="">
</blockquote>
<blockquote type="cite" class="">   DatatypeContexts<br class="">
</blockquote>
<blockquote type="cite" class="">   TraditionalRecordSyntax<br class="">
</blockquote>
<blockquote type="cite" class="">   EmptyDataDecls<br class="">
</blockquote>
<blockquote type="cite" class="">   ForeignFunctionInterface<br class="">
</blockquote>
<blockquote type="cite" class="">   PatternGuards<br class="">
</blockquote>
<blockquote type="cite" class="">   DoAndIfThenElse<br class="">
</blockquote>
<blockquote type="cite" class="">   RelaxedPolyRec<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">And the following non-Haskell2010 extensions are on by default (but not<br class="">
</blockquote>
<blockquote type="cite" class="">in Haskell2010 mode):<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">   NondecreasingIndentation<br class="">
</blockquote>
<blockquote type="cite" class="">   NoDatatypeContexts<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">I should have written the ballot consistently relative to Haskell2010,<br class="">
</blockquote>
<blockquote type="cite" class="">it’s a mixed bag right now, inherited from the survey. Or should it be<br class="">
</blockquote>
<blockquote type="cite" class="">relative to the GHC’s unnamed “default mode” (which is neither<br class="">
</blockquote>
<blockquote type="cite" class="">Haskell98 nor Haskell2010)?<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">Anyways, one goal for GHC2021 is that it will subsume this unnamed<br class="">
</blockquote>
<blockquote type="cite" class="">default mode.<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">So let’s see:<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">Interesting ones:<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">StarIsType<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ 5 votes. Those who voted no, did you do that knowing<br class="">
</blockquote>
<blockquote type="cite" class="">that it’s<br class="">
</blockquote>
<blockquote type="cite" class="">      on by default these days?<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">CUSKs<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ Legacy feature according to the docs, but the replacement<br class="">
</blockquote>
<blockquote type="cite" class="">      StandaloneKindSignatures only has 50% votes so far.<br class="">
</blockquote>
<blockquote type="cite" class="">      We probably need exactly one of the two.<br class="">
</blockquote>
<blockquote type="cite" class="">      Both are new 8.10.<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">MonomorphismRestriction<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ 4 votes. Those who voted no, did you do that knowing that it’s<br class="">
</blockquote>
<blockquote type="cite" class="">      part of Haskell2010? (I admit I didn’t)<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">ForeignFunctionInterface<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ 4 votes. Those who voted no, did you do that knowing that it’s<br class="">
</blockquote>
<blockquote type="cite" class="">      part of Haskell2010?<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">NondecreasingIndentation<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ Currently on by default, but off in Haskell2010<br class="">
</blockquote>
<blockquote type="cite" class="">      2 votes.<br class="">
</blockquote>
<blockquote type="cite" class="">      Docs at <a href="https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#context-free-syntax" class="">
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#context-free-syntax</a><br class="">
</blockquote>
<blockquote type="cite" class="">      Do we really want to turn it off? There must have been a good<br class="">
</blockquote>
<blockquote type="cite" class="">      reason for GHC to have different default behavior so far?<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">Boring ones:<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">ImplicitPrelude<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ Obviously stays<br class="">
</blockquote>
<blockquote type="cite" class="">DatatypeContexts<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ 0 votes. This goes away. Yay!<br class="">
</blockquote>
<blockquote type="cite" class="">TraditionalRecordSyntax<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ NoTraditionalRecordSyntax has zero votes, so can stay<br class="">
</blockquote>
<blockquote type="cite" class="">EmptyDataDecls<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ 10 votes, so can stay<br class="">
</blockquote>
<blockquote type="cite" class="">PatternGuards<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ NoPatternGuards has zero votes, so can stay<br class="">
</blockquote>
<blockquote type="cite" class="">DoAndIfThenElse<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ wasn’t even on the ballot, probably a consequence of<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class=""><a href="https://gitlab.haskell.org/ghc/ghc/-/issues/18631" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/18631</a><br class="">
</blockquote>
<blockquote type="cite" class="">      I assume this stays unless someone disagrees.<br class="">
</blockquote>
<blockquote type="cite" class="">RelaxedPolyRec<br class="">
</blockquote>
<blockquote type="cite" class=""> -- ^ Impossible to turn off, so this stays.<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">Sorry for the confusion, next time round will be easier, when there is<br class="">
</blockquote>
<blockquote type="cite" class="">a clear base line (i.e. GHC2021).<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">Cheers,<br class="">
</blockquote>
<blockquote type="cite" class="">Joachim<br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">-- <br class="">
</blockquote>
<blockquote type="cite" class="">Joachim Breitner<br class="">
</blockquote>
<blockquote type="cite" class=""> <a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a><br class="">
</blockquote>
<blockquote type="cite" class=""> <a href="http://www.joachim-breitner.de/" class="">http://www.joachim-breitner.de/</a><br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class=""><br class="">
</blockquote>
<blockquote type="cite" class="">_______________________________________________<br class="">
</blockquote>
<blockquote type="cite" class="">ghc-steering-committee mailing list<br class="">
</blockquote>
<blockquote type="cite" class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">
</blockquote>
<blockquote type="cite" class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote>
<br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>