<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Ah, now I understand. I think the proposal would be stronger if the Proposed Change Spec contains something like this</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>The warning category in a WARNING pragma must begin with "x-"; e.g. `{-# WARNING [x-partial] head #-}`. The reason for this is so that, the command line options `-Wx-partial` and `-Wno-x-partial` can readily be distinguished from the existing large number of built-in warning categories, such as `-Wtabs`, `-Wdodgy-import`, `-Winaccessible-code` etc. See the <a href="https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html?highlight=warning#warnings-and-sanity-checking">user manual section </a>for a complete list.</li></ul><div>Doubtless this is said already, but I did not absorb it.</div><div><br></div><div>An alternative you don't describe is to use a different -W flag to turn on and off these user-specified warnings. E.g. `-Wext:partial`, `-Wext:no-partial`. We don't think of this as a category sometimes called `partial` and sometimes called `ext:partial`. Rather we think of two flags `-W` and `-Wext`. I know this is equivalent to what the proposal said originally; now I understand it better I can see the original thinking.</div><div><br></div><div>I don't feel strongly; but once decided, it needs clear exposition.</div><div><br></div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 21 Nov 2022 at 20:32, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</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">Hi,<br>
<br>
Am Montag, dem 21.11.2022 um 13:42 +0000 schrieb Simon Peyton Jones:<br>
> > But to share some color preferences: I think the x- should be in<br>
> > the warning pragma, as currently written on GitHub. I also think we<br>
> > will soon want to be able to put the warnings into various bins<br>
> > (e.g. Wcompat, which seems very very useful for library writers for<br>
> > the same reasons it's useful for GHC itself). <br>
> > <br>
> <br>
> <br>
> I'm still a bit baffled by the "x-" bit. It just seems like extra<br>
> noise.<br>
> <br>
> Or is there an (entirely implicit) suggestion that eventually we<br>
> might want "y-" and "z-" prefixes, for some y and z? <br>
<br>
<br>
Are you baffled by the x- appearing in the flags (-Wno-x-partial) or<br>
that they also appear in the pragmas as in<br>
{-# WARNING [x-partial] "foobar" #-}?<br>
<br>
The motivation for the former is namespacing: If we don't keep custom<br>
warnings apart from those genuinely produced by the compiler, because<br>
else it’s unclear what to do with {-# WARNING [tabs] "hehe" #-}.<br>
(Last paragraph of section 2)<br>
<br>
There is a suggestion to have other prefixes later maybe, to<br>
distinguish warning categories that should be on by default from those<br>
that should go to -Wextra or -Wall etc. (No entirely implicit, though,<br>
section 6.3).<br>
<br>
The motivation for the latter is that some think it’s even more<br>
confusiong to have<br>
{-# WARNING [partial] "foobar" #-}<br>
but -Wno-x-partial, because now our mental models are confused whether<br>
partial or x-partial is the name of that warning category.<br>
<br>
<br>
I agree that this x-foo business isn't particular aesthetic.<br>
Alternatives:<br>
* We could simply allow pragmas to use built-in warning categories. <br>
Maybe the library author has a good reason to group their warning<br>
with -Wwrong-do-bind or -Wdodgy-export<br>
(but it seems a rather dangerous and confusing direction.)<br>
* We could not require a prefix, but forbid any built-in warning<br>
categories (i.e. {-# WARNING [tabs] "foo" #-} is a error).<br>
<br>
Then library code would have to rename their categories if they <br>
(accidentially) use a category name that a later GHC version starts<br>
to use themselves.<br>
* Library authors don't get to choose category names freely, but <br>
instead GHC maintains a list of allowed categories (starting with<br>
partial, but what else?). This would allow us to document their <br>
meaning precisely for consistency, and would also allow us to set <br>
their default severity (-Wdefault, -Wall etc.).<br>
<br>
Do any of these alternatives sound better to you?<br>
<br>
<br>
<br>
Cheers,<br>
Joachim<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><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>