<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
I can see the argument that we should be more opinionated about <br>
presenting features as one of<br>
* recommended (part of the language, fairly stable);<br>
* experimental (not yet resolved one way or the other); or<br>
* discouraged (supported primarily for backwards compatibility).
</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I'd be fine with that. <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><ul><li>I see the GHC20xx series as a way of codifying "recommended".</li><li> I'd add a category for "language variation" or something: things like -XStrict and -XRebindableSyntax which *change* rather than *extend* the language.</li></ul></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 1 May 2023 at 13:59, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks, I think I'm beginning to understand the position more clearly <br>
now. I can see the argument that we should be more opinionated about <br>
presenting features as one of<br>
<br>
* recommended (part of the language, fairly stable);<br>
<br>
* experimental (not yet resolved one way or the other); or<br>
<br>
* discouraged (supported primarily for backwards compatibility).<br>
<br>
To some extent GHC2021 already acts as a recommendation, but there are <br>
still many extensions that it doesn't include, and it doesn't draw a <br>
line between "experimental" and "discouraged". So perhaps one path <br>
forward would be to try to expand the set of extensions in the next <br>
GHC20xx and at the same time try to be more explicit about "discouraged" <br>
extensions that are unlikely to make it into a future GHC20xx iteration?<br>
<br>
I'm worried, however, that there are in practice many "dialects" of <br>
Haskell and hence it may be difficult to establish consensus about how <br>
to categorise many extensions.<br>
<br>
GHC2021 is described in the user's guide as "stable and conservative". <br>
Should we instead aim for "stable and liberal", i.e. adding extensions <br>
when they are unlikely to change and are useful to some people, even if <br>
others dislike them? (For example, RecordWildCards might fit into this <br>
category.) That would move us towards "one big language", but I'm not <br>
yet wholly convinced that is desirable. After all it would make the <br>
"recommended" language bigger and more complicated, and potentially <br>
constrain future evolution in ways that are hard to predict now.<br>
<br>
I think all this is mostly separable from the mechanics of warnings vs <br>
LANGUAGE pragmas vs other compiler flags. The idea that we might replace <br>
`-XNoFoo` with `-Werror=foo` is (for me at least) a distraction from the <br>
main point. (Thus, concretely, I still argue we should accept #536.)<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
On 01/05/2023 03:05, Richard Eisenberg wrote:<br>
> <br>
> <br>
>> On Apr 28, 2023, at 7:20 AM, Joachim Breitner <br>
>> <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a> <mailto:<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>>> wrote:<br>
>><br>
>> I believe [the idea about using warnings] was Richard’s.<br>
> <br>
> I indeed have been the one to advocate for this previously, and I still do.<br>
> <br>
> I think the current system of extensions presents a bewildering array of <br>
> complexity to users, and (I claim) a big source of why people say <br>
> Haskell is so complicated. Haskell, at its core, is beautifully simple! <br>
> But this fact easily gets lost.<br>
> <br>
> So my goal in advocating using warnings is to try to reduce the number <br>
> of language extensions. We would then have one big language, but users <br>
> have ways of subsetting if they like. In some sense, this is just about <br>
> marketing (it doesn't change expressiveness) but marketing is important. <br>
> It would be easy to interpret existing -X flags as warning twiddles, so <br>
> the idea is backward compatible.<br>
> <br>
> Richard<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>