[ghc-steering-committee] Language Extension Policy – Round 2

Thu Apr 27 08:09:08 UTC 2023

> Everything else can be served by either GHC20xx or warnings.

Let's unpack that statement a bit.  I think GHC20xx is a bit of a red
herring ... it doesn't change rapidly enough, and there will always be
people who want a different combination.

The thing about warnings is different.  I think you are suggesting that we
should:

   - Remove (say) MultiParamTypeClasses as an extension
   - Accept programs that use MultiParamTypeClasses unconditionally
   - But with a warning
   - That can be suppressed with -fno-warn-multi-param-type-classes

So a long {-# LANGUAGE X1, X2 #-} preamble will be replace with a long {-#
OPTIONS_GHC -fno-warn-X1 -fno-warn-X2 #-} block.

Is that what you meant by "everything else best served by warnings"?

I think that is a consistent position for extensions that use new syntax.
But

   - Not all extensions use new syntax (e.g. -XPolyKinds).
   - You say "the only exception being for experimental/unstable language
   features and language features with a performance impact", but
   - if an experimental/unstable feature uses new syntax, it would again be
      fine with "Warning: you are using an experimental feature"
      - Ditto features that use new syntax with a perf impact
      - what about RebindableSyntax or Strict, which change semantics but
      add no new syntax?
      - It's not clear to me that saying `OPTIONS_GHC -no-warn-X1` is
   superior to `LANGUAGE X1`.  In fact I mildly prefer the latter
   - It'd be a big upheaval to get from where we are, to get there

But it is a consistent position.   Are you advocating that change?

Simon

On Thu, 27 Apr 2023 at 08:35, Simon Marlow <marlowsd at gmail.com> wrote:

> This is interesting. I find myself answering "no" to "do you believe this
> use-case is best served by extensions" for almost all use-cases, the only
> exception being for experimental/unstable language features and language
> features with a performance impact. Everything else can be served by either
> GHC20xx or warnings. Yes that means being less fine-grained in some cases,
> but that might be a good tradeoff between flexibility for users and
> complexity in the compiler - fewer combinations of extensions to consider
> would simplify things and leave less room for bugs.
>
> Answers below:
>
> On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>>
>> X.1: do you believe that this a use-case that GHC should support? (yes/no)
>> X.2: regardless of your answer in X.1, if GHC supports this use-case,
>>   do you believe that this use-case is best served by extensions. (yes/no)
>> X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)
>> X.2.N: if you've answered “no” to X.2: what mechanism would you rather
>>   see supporting this use-case (free form)
>>
>> The 13 use-cases are
>>
>> 1. Gain early access to experimental or unstable features
>>    (e.g. because they're working on a research prototype, or because
>>    the feature is valuable enough to them to forgo some stability)
>>
>
> 1. yes
> 2. yes
> 2.Y no
>
>
>> 2. Restrict the use of more complex features (e.g. for easier
>>    onboarding of new developers or as educators to teach a
>>    well-delimited subset of the language)
>>
>
> 1. yes
> 2. no
> 2.N warnings, -Werror=feature
>
>
>> 3. Restrict the use of novel features since the last established
>>    standard/report.
>>
>
> 1. yes
> 2. no
> 2.N -XHaskell2010 and/or warnings
>
>
>> 4. Restrict the use to features that they don't like (e.g. controversial
>>    features like RecordWildcard or ImplicitParameters)
>>
>
> 1. yes
> 2. no
> 2.N warnings
>
>
>> 5. Name/refer to a particular feature when talking/writing/searching
>>    about it.
>>
>
> 1. yes
> 2. no - we don't need to support extensions to be able to name language
> features.
> 2.N continue to use the names we have now, but without supporting -XFoo
> for all extensions
>
>
>> 6. Restrict the use of features which require support from outside
>>    the Haskell ecosystem that can't be taken for granted (I think this
>>    concerns only UnicodeSyntax)
>>
>
> 1. yes
> 2. no
> 2.N warnings
>
>
>> 7. As library authors, to signal which features the library actually
>>    uses, hence which version of GHC the library is compatible with.
>>
>
> 1. yes
> 2. no
> 2.N GHC20xx
>
>
>> 8. Retain access to deprecated features to smooth out migration over
>>    the deprecation period.
>>
>
> 1. yes
> 2.no
> 2.N GHC20xx
>
>
>> 9. Retain access to deprecated features indefinitely.
>>
>
> 1. no
>
>
>> 10. Change the default behaviour of (part of) the language
>>     (e.g. StrictData, I think some of the dependent Haskell work falls
>>     in this category, but I can't pinpoint an example)
>>
>
> 1. yes
> 2. no
> 2.N GHC20xx
>
>
>> 11. Extend the language in a way that is not backward compatible
>>     (e.g. OverloadedList, probably some dependent Haskell things too)
>>
>
> 1. yes
> 2. no
> 2.N GHC20xx
>
>
>> 12. Enable features whose mere presence has a performance impact
>>     (e.g. Template Haskell, and that's probably it)
>>
>
> 1. yes
> 2. yes
> 2.Y no
>
>
>> 13. CPP (this one is very unique isn't it?)
>>
>
> 1. yes
> 2. no
> 2.N it should probably be a flag
>
>
>> _______________________________________________
>> 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/20230427/cf5a3ec8/attachment.html>