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

27 Apr 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  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 
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@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

Simon Peyton Jones