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

Sun Sep 3 00:15:39 UTC 2023

On Sat, 2 Sep 2023 at 9:56 PM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> 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
>
> I do not consider this significantly more work it’s really just passing
-DEXPERIMENTAL to the build. But we don’t even need those during our
_stable_ build releases. We have nighties and we could build nightlies with
-DEXPERIMENTAL. Thus everyone who wants unstable/experimental features can
get them through nightly builds.

This is also what other languages do.

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

Yes, very much so.

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.
>

That’s why I’m advocating for a separate build. So they don’t get any
warning and can enable the features to their heats content. But if you do
not use the experimental build (e.g. a nightly) you can not, not even by
accident, enable those features.

By having them in release builds you open the door to lengthy discussions
of why some features a _stable_ compiler offers should _not_ be used. And
then have to have reviewers be careful about which extensions and other
features are enabled or not. It basically puts a lot of work on teams to
reign in on accidental usage of experimental/unstable features. So then we
end up building tools on-top, lingers, CI checks to run with
-Werror=XExerimental, … all just to ensure something which should not be
there by construction.

I simply do not believe that experimental or unstable features should be
part of stable releases. What is the definition of stable at that point?

The practice that we put experimental/unstable features into our stable
releases is something this proposal seems to cement, which is why I’m so
much against it in this form. I fundamentally believe that if we put
experimental/unstable features into our releases we must not call them
stable releases. So we are left with experimental/unstable releases only.

We’ve had discussions around this before:
- Michael Snoymans Boring Haskell[1]
- Simple Haskell[2]
- George Wilson’s talk on Cultivating an Engineering Dialect[3]

I hope this helps clarify my stance on this proposal.

Moritz

—
[1]:
https://www.snoyman.com/blog/2019/11/boring-haskell-manifesto/
[2]:
https://www.simplehaskell.org
[3]: https://www.youtube.com/watch?v=L4h6VegK1BI

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/20230903/7bd27639/attachment-0001.html>