[ghc-steering-committee] #380 GHC2021: StarIsType

[Tom Harding]

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 <trupill at gmail.com<mailto:trupill at gmail.com>> wrote:

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.

Regards,
Alejandro

On 4 Dec 2020 at 12:07:33, Tom Harding <tomjharding at live.co.uk<mailto:tomjharding at live.co.uk>> wrote:
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.

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.

Thanks,
Tom

On 4 Dec 2020, at 10:57, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:

Hi,

Am Freitag, den 04.12.2020, 09:57 +0000 schrieb Simon Marlow:
> 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#context-free-syntax
      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 at joachim-breitner.de<mailto:mail at joachim-breitner.de>
 http://www.joachim-breitner.de/


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/445b26ef/attachment-0001.html>