[ghc-steering-committee] Language Extension Policy – Round 2
Simon Marlow
marlowsd at gmail.com
Fri Apr 28 08:17:37 UTC 2023
Good! I'm glad we're discussing where this alternative design leads. I'm
not sure whether I'm 100% advocating for it - it may be that ultimately
it's not enough of an improvement over extension flags to warrant the
churn. But I think it's worthwhile to explore it. (to be clear I don't
think the idea of using warnings was mine, I forgot who originally
suggested it but it came out of the discussion on the GDoc we had earlier)
On Thu, 27 Apr 2023 at 09:07, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:
> > 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
>
> Only with GHC2021 and later
>
> - But with a warning
>
> which is disabled by default
>
> - That can be suppressed with -fno-warn-multi-param-type-classes
>
> maybe we call it -WMultiParamTypeClasses to keep the naming consistent. So
-Werror=MultiParamTypeClasses would be the way to disable it.
> So a long {-# LANGUAGE X1, X2 #-} preamble will be replace with a long {-#
> OPTIONS_GHC -fno-warn-X1 -fno-warn-X2 #-} block.
>
No, most use cases would be using `{-# LANGUAGE GHC2021 #-}` or whatever.
Use cases that wanted to use GHC2021 but disable specific extensions would
need a `{-# LANGUAGE -Werror=whatever #-}` or the equivalent in the .cabal
file.
>
> I think that is a consistent position for extensions that use new syntax.
> But
>
> - Not all extensions use new syntax (e.g. -XPolyKinds).
>
> Sure, so if you want to disable PolyKinds then you must use a GHC20xx
version that doesn't include it. This is of course less flexible than what
we currently have. But it might be advantageous:
- We don't have to consider what happens when you turn off PolyKinds in
combination with all the other extensions, and make all those combinations
behave in some well-defined way (or, disallow certain combinations with an
error when the combination doesn't make sense). We know that PolyKinds is
only enabled along with all the other extensions in GHC2024 or whatever.
Note that other languages do similar things: you can't turn off individual
extensions in C++17 for example.
- We're massively reducing the space of language variants to a set of a
few language versions that we have carefully curated. That is, I postulate,
a very good thing for most users and for the language in general.
> - 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"
>
> We could only do that for things with genuinely new syntax (not stolen
syntax!). So e.g. OverloadedLists couldn't be a warning, it has to be an
experimental extension.
>
> - Ditto features that use new syntax with a perf impact
> - what about RebindableSyntax or Strict, which change semantics but
> add no new syntax?
>
> Both of those cases should arguably be flags instead of language
extensions. `{-# LANGUAGE -frebindable-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
>
> Indeed!
> But it is a consistent position. Are you advocating that change?
>
I'm not sure, but as I said at the top, I think it's worth exploring.
Cheers
Simon
>
> 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/20230428/da936e0d/attachment-0001.html>
More information about the ghc-steering-committee
mailing list