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

Fri Dec 4 12:49:06 UTC 2020

I hadn't seen this thread, sorry Alejandro, so let me copy my remarks from
the main thread

I would like to urge us not to include NoStarIsType in the defaults until
> we include StandaloneKindSignature as well. Mostly on aesthetic grounds.
>
> It's fairly obvious that NoStarIsType will be the default eventually. I
> just think that GHC2021 is premature.
>

On Fri, Dec 4, 2020 at 12:24 PM Tom Harding <tomjharding at live.co.uk> wrote:

> 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> 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> 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
>>
>
> _______________________________________________
> 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/ba271014/attachment-0001.html>