[ghc-steering-committee] Urgent: exension life cycle proposal

[Eric Seidel]

There's a non-normative and a normative component to this proposal.

The non-normative piece says that there should be a categorization scheme for language extensions. That is inarguable in my opinion. The proposal also suggests an initial framework of four categories, which seems like a reasonable place to start. (Vlad says we should first figure out how to map all extensions to the categories; I disagree. We can iterate on the categories over time, as needed.)

The normative piece of the proposal says that we should start warning on the use of any Deprecated, Unstable, or Legacy extensions. This seems like a reasonable ideal, but the practicality kind of hinges on the bucketing of specific extensions (and on Richard's question of how `default-language` is interpreted). The authors give some recommendations of how to bucket particular extensions, but it's not exhaustive and I also view it as the authors' desire rather than a specific commitment of the proposal.

So in my view:

* Yes, we should have a framework for categorizing the jungle of language extensions, and the proposal seems like a fine starting point.
* Yes, we should have a set of warnings for users who would like to forbid certain categories of extensions.
* We should probably defer any decisions about default enablement of warnings until we have a complete proposed categorization. And that discussion should include some analysis of the pervasiveness of "deprecated", "unstable", and "legacy" extensions so we can judge the amount of churn. Just like any other discussion about deprecation.

Eric

On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote:
> I've just posted on the GitHub ticket. I remain against the proposal in 
> its current form, mostly because it means (if I understand correctly) 
> that everyone who says `default-language: Haskell2010` will get 
> warnings.
>
> Richard
>
>> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>> 
>> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com> wrote:
>>> A few things make this not a straightforward thumbs up for me, though I'm not strongly against.
>>> 
>>> What is the interaction with GHC20xx? Presumably we want to say something like GHC20xx will never include any Deprecated or Legacy extensions? What about Unsable? if an extension transitions from Stable -> Legacy, would we remove it from the next GHC20xx?
>> 
>> Ah, I just noticed that the proposal does say something about this:
>> 
>>> For existing, or future, language sets such as `GHC2021` or `Haskell98`, it is expected that none of the contained extensions would be `Unstable`. However, this proposal does not seek to impose any particular policy on the inclusion of extensions into language sets - the developers and the steering committee are always in the best position to make a decision about a concrete extension and extension set.
>>  
>> OK.
>> 
>> Simon
>> 
>> 
>>> 
>>> Something doesn't feel quite right about the warning system. If a module can start with
>>> 
>>> {-# OPTIONS_GHC -Wno-XDeprecated #-}
>>> {-# LANGUAGE OverlappingInstances #-}
>>> 
>>> and silently use an extension that the {build system, user, project} wanted to disallow, have we achieved anything? Compare this to the current situation, where the environment can say -XNoOverlappingInstances and code can override that with {-# LANGUAGE OverlappingInstances #-} - there's essentially no difference, we just added another layer of disable/override that isn't buying us anything.
>>> 
>>> (note I'm viewing this through the spectacles of -Werror, because I've come to believe that warnings are essentially not useful unless given teeth with -Werror.)
>>> 
>>> Cheers
>>> Simon
>>> 
>>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <vlad.z.4096 at gmail.com> wrote:
>>>> I agree that we need a categorisation of extension language flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set of labels. In fact, I wouldn't want to commit to any particular categorisation before we actually go through all the extensions in GHC and see for ourselves that they can be adequately categorized according to the proposed system.
>>>> 
>>>> The proposal says "classifications of individual language extensions will be left to a future proposal". Well, I am skeptical that this separation makes sense. I would much prefer if we were discussing a concrete categorisation proposal, not just a set of four labels whose implications I can't fully grasp.
>>>> 
>>>> Vlad
>>>> 
>>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>>>>> Dear Simon, Vlad, Eric, Chris, Moritz
>>>>> 
>>>>> I would love to hear from you about this proposal.  *Please*. 
>>>>> 
>>>>> I plan to accept it unless I hear dissent.  But I would much rather have an explicit response from you than take silence as assent.  You are a member of the committee, after all!
>>>>> 
>>>>> My apologies if I have missed your reply
>>>>> 
>>>>> Simon
>> _______________________________________________
>> 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