[ghc-steering-committee] #380 GHC2021: Current status

Tom Harding tomjharding at live.co.uk
Fri Dec 4 11:07:33 UTC 2020


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



More information about the ghc-steering-committee mailing list