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

Alejandro Serrano Mena trupill at gmail.com
Fri Dec 4 11:14:47 UTC 2020


 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> 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>
> 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
>
>  http://www.joachim-breitner.de/
>
>
>
> _______________________________________________
>
> ghc-steering-committee mailing list
>
> 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
> 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/f6e80977/attachment-0001.html>


More information about the ghc-steering-committee mailing list