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

[Simon Marlow]

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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230901/5e4d364b/attachment.html>