[ghc-steering-committee] Language Extension Policy – Round 3
Simon Marlow
marlowsd at gmail.com
Wed Aug 30 10:43:19 UTC 2023
Apologies also from me, I took the whole 6-week school holidays off work
and I'm only just getting back into it.
On Tue, 1 Aug 2023 at 08:17, Adam Gundry <adam at well-typed.com> wrote:
>
> * I think it would be a good idea for someone to rewrite the user's
> guide so that it represents the latest GHC20xx as the base language
>
I think even if we do nothing else, this would be a great step forwards.
Right now, extensions are the first-class mechanism, and GHC20xx is
expressed as a group of extensions. Ideally it should be the other way
around.
If we made a few changes to documentation and error messages to steer
people towards GHC20xx and away from extensions, in the long term that
would have the effect of making explicit extensions less common and more of
an experimental/advanced feature. GHC20xx would be the norm, and code that
people encounter would often be in one of the (few) GHC20xx dialects. That
would simplify things from the user's perspective, with zero impact on the
implementation. We seem to be more worried by the user-facing impact of
extension-fatigue rather than the implementation complexity of making 2^n
combinations work (going by Simon's comments, the implementation impact
isn't really a problem).
Cheers
Simon
> (e.g. so BangPatterns are documented as a feature of the language, with
> a brief mention that -XNoBangPatterns exists). We could rename chapter 6
> "Language extensions" to be "The language GHC supports". I suspect it's
> probably better to keep it organised by topic rather than bifurcating it
> into GHC20xx vs non-GHC20xx features, not least because in some cases it
> may need to document the fact that the extension's status changed over
> time.
>
> * Error message recommendations can surely be improved to be more
> sensible (not telling users to enable certain extensions).
>
> * I'm sceptical that reducing choice (e.g. GHC2024 mandating certain
> extensions but prohibiting others, or making it impossible to disable
> certain extensions) is really valuable. We can certainly forbid actually
> problematic interactions (by making it an error to enable two features
> that don't make sense together). But I'm unconvinced that we get any
> real conceptual or implementation benefit from a general prohibition.
>
> Cheers,
>
> Adam
>
>
> On 31/07/2023 09:41, Arnaud Spiwack wrote:
> > I think we've gathered as much data as we can here. Eventually, we'll
> > probably want to use this thread to come up with a GHC proposal along
> > the lines of what Joachim came up with (extensions only apply to certain
> > languages), as it seems like it may be very desirable and there's a
> > clear consensus that retiring extensions altogether is undesirable.
> >
> > I'm not sure yet what our next round of discussion will be about. I'll
> > be on holiday next week and the week after, so I'd like to start
> > something before then (but I'm making no promises: I need to collect my
> > thoughts).
> >
> > On Fri, 21 Jul 2023 at 19:49, Richard Eisenberg <lists at richarde.dev
> > <mailto:lists at richarde.dev>> wrote:
> >
> > My views here:
> >
> > * This whole push is like weeding an overgrown garden. Weeding is
> > rarely the highest-priority task -- but if you never do it, the lack
> > of care shows. I'm in support of doing *something* here.
> > * I think our users would benefit most from a clear delineation of
> > the status of the various extensions. There are two challenges here:
> > defining the categories and then doing the categorization. I believe
> > this trek (led heroically by Arnaud) is about tackling that first
> > challenge. David's proposal is also squarely in this space
> > * I'm against doing anything backward-incompatible about extensions.
> > Extensions are generally seen as bureaucratic overhead; causing
> > breakage because of them would be pedantry run amok. But the various
> > ideas already proposed all sound like the could work to reduce the
> > number of extensions while not causing backward incompatibility.
> >
> > Richard
> >
> >
> >> On Jul 17, 2023, at 6:16 AM, Moritz Angermann
> >> <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>>
> >> wrote:
> >>
> >> My view is, I don’t have much of a concrete opinion on this. I
> >> *do* have a very strong belief around backwards compatibility. I
> >> think that the constant churn that breaking changes cause are a
> >> major detriment to Haskell adoption. If I were in a position to
> >> make a technological decision. I’m not sure I’d be able to choose
> >> Haskell.
> >>
> >> I do think we have *way* too many extensions, and their
> >> interaction is hard to understand for new developers. I also think
> >> we should put a lot of the new developments (research compiler)
> >> behind a -DRESEARCH or -DEXPERIMENTAL flags and have separate
> >> binary distributions for those, clearly marked as such.
> >>
> >> But all this is orthogonal to this.
> >>
> >> Reducing the amount of language extension complexities, by
> >> building groupings seems sensible. Having this come along with the
> >> compiler suggesting upgrading to language groups (GHC20XX) to
> >> reduce a lot of extension noise in files and better understood
> >> extensions interaction (ideally with the compiler providing the
> >> relevant patches or auto migration), would be something I consider
> >> sensible.
> >>
> >> Removing extensions that lead to existing, but then broken code is
> >> something I’m *highly* opposed to. With lengthily deprecation
> >> cycles and some monitoring across the ecosystem this might be
> >> doable. I will however oppose none or short deprecation cycles.
> >>
> >> Ultimately for the specific choice which extensions are grouped,
> >> and how, I’m not the right person to ask.
> >>
> >> On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones
> >> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> >> wrote:
> >>
> >> My personal view is this.
> >>
> >> * I find it hard to bring energy to this meta-conversation
> >> about extension policy. For me it's a funny combination
> >> of too abstract (what are we trying to achieve?) and too
> >> detailed (/thirteen /possible use cases for each
> extension?).
> >> * My general position is: let's define well-specified
> >> extensions, and let users choose which ones to use.
> >> * I'm not against grouping them into GHC20xx groups, but I
> >> don't have a strong view about what should be in which
> >> groups. My instinct is to produce GHC20xx rather
> >> infrequently, much less than annually.
> >> * David's recent extension policy proposal
> >> <https://github.com/ghc-proposals/ghc-proposals/pull/601>makes
> sense to me. It is simple, concrete, and actionable.
> >>
> >> If all this is important to others I'm not against continuing
> >> the conversation. But if it were me I'd just focus around
> >> agreeing David's proposal (if there is general support), and
> >> then let it be.
> >>
> >> None of this is to criticise Arnaud and Joachim's work in
> >> herding cats. Thank you -- it's a tricky topic! I'm just not
> >> sure that it is the highest priority problem. But: remember
> >> that I am an out-lier. This conversation mostly impacts
> >> users, and I am unrepresentative of that constituency.
> >>
> >>
> >> Simon
> >>
> >> On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack
> >> <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
> wrote:
> >>
> >> This discussion seems to be of little interest to most of
> >> us. I must confess that I'm quite surprised: I expected a
> >> rather heated debate. To try and get a better
> >> understanding of where everybody stands, it would help me
> >> to have everyone post even a short comment, even
> >> half-baked, expressing their sentiment on the issue.
> >>
> >> Do pay attention to Joachim's idea, which is not in my
> >> original email, whereby extensions could only be made
> >> valid under a subset of base languages (Haskell98,
> >> Haskell2010, GHC20xx).
> >>
> >> On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones
> >> <simon.peytonjones at gmail.com
> >> <mailto:simon.peytonjones at gmail.com>> wrote:
> >>
> >> A question which can matter as part of this
> >> discussion is how much of a maintenance burden is
> >> having so many extensions?
> >>
> >>
> >> Generally, not much provided they are well-designed
> >> and orthogonal. Some flag-testing would disappear if
> >> the feature is permanently on. But not much
> >> complexity beyond that, usually.
> >>
> >> Simon
> >>
> >> On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack
> >> <arnaud.spiwack at tweag.io
> >> <mailto:arnaud.spiwack at tweag.io>> wrote:
> >>
> >> *@Chris:*
> >> That's a long email 🙂. I think that when people
> >> complain about committees, what they complain
> >> about is too many people deciding, not too few. At
> >> any rate, as the GHC steering committee we are the
> >> designated caretakers of GHC's flavour of Haskell.
> >> We are required to make decisions on proposals,
> >> and often asked to consult on what the best course
> >> of action for a proposal is. 2^n - We use a set of
> >> principles as guides. Reducing the number of
> >> dialects of GHC can either be a goal or a
> >> non-goal. But the only alternative to choosing is
> >> not making a choice. And we'd be left in the
> >> current situation, where different committee
> >> members pull in different directions based on what
> >> extensions mean for them, and whether a proposal
> >> is accepted in a shape or another is largely
> >> dependent on which committee member had more brain
> >> cycles that week. Some of us have started this
> >> process of thinking deeply about extensions
> >> because we observed that there was a disconnect
> >> within the committee. And we believe that we owe
> >> the community better than this.
> >>
> >> That being said, I'm not advocating or even
> >> proposing sweeping changes (a big change in policy
> >> would require, like any, a proposal). I'm asking
> >> us to dream a little together and think about what
> >> we believe would be most beneficial for the
> >> language. The main outcome that I'm trying to
> >> achieve is a new set of principles relating to
> >> extensions.
> >>
> >> *@Joachim/@Simon:*
> >> I think both of you are bringing concern about
> >> backward compatibility. I think there are two
> >> questions:
> >> 1. Moving forward, we could advertise extensions
> >> as being temporary, and if you use them, you
> >> should expect to have to rewrite part of your code
> >> in the future. Is the extra work worth it?
> >> 2. All the extensions in the past that we've been
> >> used to turn on on a fine-grain basis represent an
> >> enormous amount of libraries. Some are basically
> >> unmaintained, having been robust enough to go
> >> untouched for 10+ years. Rewriting this would be a
> >> tremendous effort. Is the extra work worth it?
> >>
> >> I take your comments as saying that the answer to
> >> (2) is almost certainly “no”. What's your answer
> >> to (1)? I can see an argument for saying that
> >> Haskell being a research language, extensions take
> >> longer than, say, in Rust, to be eventually rolled
> >> in. As such, we actually expect many to have
> >> extensions turned on, and for long enough that it
> >> would become a liability to erase the extension in
> >> the future.
> >>
> >> One difficulty is that it's rather fraught to let
> >> code with `-XSomeExtension` compile while not
> >> documenting what `-XSomeExtension` does. We could
> >> make it conspicuous in the manual that the
> >> extension is deprecated. But would
> >> `--show-options` also contain it? We also need to
> >> make sure that the deprecated extension is not
> >> autocompleted by IDEs (I guess this is a setting
> >> for GHCi). I think this is started to look like
> >> the Haskell Foundation's Stability Working Group's
> >> proposal mentioned above.
> >>
> >> *@Joachim:*
> >> The idea of having extensions work only against
> >> certain languages is intriguing. I think it needs
> >> some refinement: First, -XFuzzyTypes would work
> >> against GHC2024 or later, until it's folded into a
> >> GHC20xx. And, probably, you'll still want to be
> >> able to call `-XNoFuzzyTypes` on some of the
> >> GHC20xx where it is folded (maybe just 1), at
> >> least if it causes some compatibility issues (I
> >> don't think -XDerivingFunctor is of the sort), in
> >> order to smooth out transition.
> >>
> >> Another question on this approach is: how would
> >> the user guide present this information without
> >> flooding the reader with extensions that don't
> >> apply to the GHC20xx they're using?
> >>
> >> *@all*:
> >> A question which can matter as part of this
> >> discussion is how much of a maintenance burden is
> >> having so many extensions? From a pure
> >> implementation-of-GHC point of view. Personally,
> >> it's never really been in my way (which may simply
> >> mean that I don't contribute a lot), so I'm
> >> focussing, in this discussion, on the impact on
> >> Haskell programmers. But the impact on GHC
> >> developers is definitely relevant.
> >>
> >> --
> >> Arnaud Spiwack
> >> Director, Research at https://moduscreate.com
> >> <https://moduscreate.com/> and https://tweag.io
> >> <https://tweag.io/>.
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> <mailto:ghc-steering-committee at haskell.org>
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >>
> >>
> >>
> >> --
> >> Arnaud Spiwack
> >> Director, Research at https://moduscreate.com
> >> <https://moduscreate.com/> and https://tweag.io
> >> <https://tweag.io/>.
> >>
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> <mailto:ghc-steering-committee at haskell.org>
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >>
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >> <mailto:ghc-steering-committee at haskell.org>
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > <mailto:ghc-steering-committee at haskell.org>
> >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >
> >
> >
> > --
> > Arnaud Spiwack
> > Director, Research at https://moduscreate.com <https://moduscreate.com>
> > and https://tweag.io <https://tweag.io>.
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> _______________________________________________
> 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/20230830/9b257e45/attachment-0001.html>
More information about the ghc-steering-committee
mailing list