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

[Simon Peyton Jones]

>
> Again, my point is that Unstable extensions should _not_ be in the Stable
> ghc releases, and as such anything that's in
>
the stable ghc releases should be considered stable.
>

I don't agree with this. To follow your plan we would have to do this:

   - Release ghc-9.10
   - Release ghc-9.10-experimental
   - The two are bit-for-bit identical, except that in ghc-9.10 a bunch
   experimental extensions, available in ghc-9.10-experimental, are unavailable

This would clearly add to the overheads of a release, and add confusion in
the user base.  What would it gain that is not gained by supporting
-Werorr=XExperimental?  That is, if you don't want access to experimental
features, just make it an error to use them -- something this proposal
enables for the first time. I seex many costs but no benefits in having two
copies of the same compiler.

You clearly feel strongly about this so I feel I am missing something
important.

Maybe you want -Werror=XExerimental to be the default?  So that to use an
experimental feature the user would not only have to invoke it by name, but
also switch off the error its use triggers.  That would cause a huge amount
of transitional churn which users would hate us for, but I can see some
logic in it.

Simon

On Sat, 2 Sept 2023 at 03:49, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> This is a bit hard for me. But here it goes.
>
> IMO _every_ extension enabled in the public release of GHC _are_ stable by
> definition. It's a stable release, thus
> the available extensions are also those the GHC team decides to be stable.
> While I'm very much in favour of having
> a clearer picture of what we currently consider extensions to be. I do not
> believe _Unstable_ extensions should
> ever be part of a public stable release. I also don't think the
> distinction between Legacy and Deprecated is easy to
> understand for the end user. Either the extension is supposed to be used,
> or not. Stable or Deprecated. The fact that
> we'll keep some extension around for what is effectively an infinite
> deprecation period is a technicality in my opinion.
>
> This puts my vote probably fairly square into Alternative 6.3; I don't
> think 6.1 is useful. Having to tell people to RTFM
> comes across pretty passive aggressive all the time. Also it's the
> compiler's knowledge as to what is deprecated or not
> and it should report this. 6.2 is even worse, as it now has two components
> that need to be kept in sync, while the
> extensions are pretty much integral to GHC. Hence GHC has this knowledge
> and should report it. 6.4 and 6.5 are in
> the same line as the Legacy/Deprecated extra complexity bucket to me.
>
> Again, what's shipped in the stable release _is_ stable to me. And as such
> any _unstable_ extensions should _not_
> be in stable ghc releases. Other languages have separate channels for
> this. I've also proposed multiple times to have
> either two separate development branches: stable + experimental (stable
> being periodically merged into experimental),
> and cutting _stable_ releases from stable, potentially offering
> _experimental_ releases from the experimental branch.
> And alternative model is to have a single branch (as I do understand that
> getting stuff from the experimental branch
> migrated into stable could be a bit messy), but have every _unstable_
> extension behind a -DEXPERIMENTAL compile
> time flag. The same flag could be used to produce experimental ghc
> releases for 3rd parties to consume.
>
> Again, my point is that Unstable extensions should _not_ be in the Stable
> ghc releases, and as such anything that's in
> the stable ghc releases should be considered stable. If I want to play
> with bleeding edge features, I should have to use
> a completely separate compiler for this (again, other languages _do_
> follow this approach).
>
> And that leaves us with stable extensions in GHC, for which we eventually
> see that we have better facilities now or
> learned over time that these extensions (despite being stable), have
> reached their end of life. In that case they should
> be marked as deprecated with appropriately long deprecation cycles.
>
> GHC already has a ton of flags, let's try not to add that many more to it.
> Ultimately someone needs to keep all of this
> in their head, while also trying to get their job done. And for some this
> job is 9-5, five days a week only; no late night
> hacking sessions, no weekend projects; but instead soccer
> practice, cycling, spending time with their family. If we want
> to make haskell successful, we need to make sure that in that people can
> be effective and productive and solve real
> world problems in the 40hs they have per week; and not study manuals, or
> flags (and if they see one of the many
> unknown flags, go study those flags) more than absolutely necessary to get
> work done.
>
> In summary, I don't see myself supporting this proposal as it adds too
> much complexity and sets in stone that unstable
> extensions are part of a stable compiler. I'm happy to see that the "only
> deprecations" option is listed as an alternative
> in 6.3, even though I do not agree with the assessment that we need more
> nuance for users. Extension in my opinion
> should only be stable, or deprecated. And the end user should never see
> unstable extensions, unless they _explicitly_
> asked for an experimental/unstable compiler.
>
> Moritz
>
> On Sat, 2 Sept 2023 at 08:24, Eric Seidel <eric at seidel.io> wrote:
>
>> 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
>> _______________________________________________
>> 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/20230902/32b3a64f/attachment-0001.html>