[ghc-steering-committee] Language Extension Policy – Round 2

[Simon Peyton Jones]

I'm in the "stable and liberal" camp.  My general view is that we should
offer extensions and let our users decide which ones they want to use.

I can see the argument that we should be more opinionated about
> presenting features as one of
>   * recommended (part of the language, fairly stable);
>   * experimental (not yet resolved one way or the other); or
>   * discouraged (supported primarily for backwards compatibility).
>

I'd be fine with that.

   - I see the GHC20xx series as a way of codifying "recommended".
   -  I'd add a category for "language variation" or something: things like
   -XStrict and -XRebindableSyntax which *change* rather than *extend* the
   language.

Simon

On Mon, 1 May 2023 at 13:59, Adam Gundry <adam at well-typed.com> wrote:

> Thanks, I think I'm beginning to understand the position more clearly
> now. I can see the argument that we should be more opinionated about
> presenting features as one of
>
>   * recommended (part of the language, fairly stable);
>
>   * experimental (not yet resolved one way or the other); or
>
>   * discouraged (supported primarily for backwards compatibility).
>
> To some extent GHC2021 already acts as a recommendation, but there are
> still many extensions that it doesn't include, and it doesn't draw a
> line between "experimental" and "discouraged". So perhaps one path
> forward would be to try to expand the set of extensions in the next
> GHC20xx and at the same time try to be more explicit about "discouraged"
> extensions that are unlikely to make it into a future GHC20xx iteration?
>
> I'm worried, however, that there are in practice many "dialects" of
> Haskell and hence it may be difficult to establish consensus about how
> to categorise many extensions.
>
> GHC2021 is described in the user's guide as "stable and conservative".
> Should we instead aim for "stable and liberal", i.e. adding extensions
> when they are unlikely to change and are useful to some people, even if
> others dislike them? (For example, RecordWildCards might fit into this
> category.) That would move us towards "one big language", but I'm not
> yet wholly convinced that is desirable. After all it would make the
> "recommended" language bigger and more complicated, and potentially
> constrain future evolution in ways that are hard to predict now.
>
> I think all this is mostly separable from the mechanics of warnings vs
> LANGUAGE pragmas vs other compiler flags. The idea that we might replace
> `-XNoFoo` with `-Werror=foo` is (for me at least) a distraction from the
> main point. (Thus, concretely, I still argue we should accept #536.)
>
> Cheers,
>
> Adam
>
>
> On 01/05/2023 03:05, Richard Eisenberg wrote:
> >
> >
> >> On Apr 28, 2023, at 7:20 AM, Joachim Breitner
> >> <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> >>
> >> I believe [the idea about using warnings] was Richard’s.
> >
> > I indeed have been the one to advocate for this previously, and I still
> do.
> >
> > I think the current system of extensions presents a bewildering array of
> > complexity to users, and (I claim) a big source of why people say
> > Haskell is so complicated. Haskell, at its core, is beautifully simple!
> > But this fact easily gets lost.
> >
> > So my goal in advocating using warnings is to try to reduce the number
> > of language extensions. We would then have one big language, but users
> > have ways of subsetting if they like. In some sense, this is just about
> > marketing (it doesn't change expressiveness) but marketing is important.
> > It would be easy to interpret existing -X flags as warning twiddles, so
> > the idea is backward compatible.
> >
> > Richard
>
> --
> 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/20230501/c4f8b7bf/attachment-0001.html>