Hi, Am Donnerstag, dem 17.11.2022 um 11:17 +0100 schrieb Arnaud Spiwack:

For the bikeshedding question, the mathematician in me believes that using `WARNING [partial]` is more canonical. Except that there is the `deprectations` category which is suppressed with `-Wno-deprecations` (the proposal solves this in saying that `-Wno-deprecations` is actually an alias for `-Wno-x-deprecations`, why not). Pragmatically, though, the more I think about it, the more I'm favouring enforcing that the warning author write `WARNING [x-partial]` (it is also permitted to write `[deprecations]` without an x, which would avoid introducing `x-deprecations` gratuitously). The explicitness here, I think, helps. The warning category would _always_ be called `x- partial`. It's easier to process, easier to google. The cost is tiny.

thanks for the input. I also have the sense that it will be easier to understand the feature if users sees x-foo everywhere (source and command lines), and it allows later extensions. I’ll turn this into a suggestion on the PR. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

But to share some color preferences: I think the x- should be in the warning pragma, as currently written on GitHub. I also think we will soon want to be able to put the warnings into various bins (e.g. Wcompat, which seems very very useful for library writers for the same reasons it's useful for GHC itself).

I'm still a bit baffled by the "x-" bit. It just seems like extra noise. Or is there an (entirely implicit) suggestion that eventually we might want "y-" and "z-" prefixes, for some y and z? Simon On Mon, 21 Nov 2022 at 12:55, Richard Eisenberg wrote:

I'm strongly in favor of this proposal, and I think that would remain true regardless of the shed colors.

But to share some color preferences: I think the x- should be in the warning pragma, as currently written on GitHub. I also think we will soon want to be able to put the warnings into various bins (e.g. Wcompat, which seems very very useful for library writers for the same reasons it's useful for GHC itself). But there's nothing stopping us from expanding this syntax later, e.g. {-# WARNING [x-furble@compat] ... #-} or some such, and maybe it's better to gain experience before overengineering.

Richard

...

On Nov 16, 2022, at 2:16 PM, Joachim Breitner wrote:

Dear all,

Adam has submitted “WARNING pragmas with categories” for committee consideration: https://github.com/ghc-proposals/ghc-proposals/pull/541

https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/0...

...

I’m shepherding that one myself.

WARNING pragmas can come with categories now: {-# WARNING [partial] head "This is a partial function, …" #-}

so that one can sensible group them and allow the user to silence the warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just like with the built-in warning categories.

No language pragma is required (presumably since we are already in a GHC-specific pragma).

These custom warnings categories need to be prefixed with `x-` on the command line to keep them separate from the built-in warnings. This is a decision where I am inviting the committee to bikeshed: * Do we really need a separator, or is it ok for library-defined warnings to join a built-in category? * Should it be used in syntax as well (WARNING [x-partial]) for easier predictability and later extension to other prefixes (see below)?

All these custom warning categories are part of the severity group -Wdefault (on by default, not errors). I expect we eventually want to give the programmer control over the severity (off by default, error by default, part of -Wcompat, etc…), but it’s not immediately clear what to do here, so we can add it latter (another optional field in the pragma, a separate pragma, a naming convention like xe-foo, or something else). Please complain if you think this needs to be addressed here.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Ah, now I understand. I think the proposal would be stronger if the Proposed Change Spec contains something like this - 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 user manual section https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html?highl...for a complete list. Doubtless this is said already, but I did not absorb it. 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. I don't feel strongly; but once decided, it needs clear exposition. Simon On Mon, 21 Nov 2022 at 20:32, Joachim Breitner wrote:

Hi,

Am Montag, dem 21.11.2022 um 13:42 +0000 schrieb Simon Peyton Jones:

...

...

But to share some color preferences: I think the x- should be in the warning pragma, as currently written on GitHub. I also think we will soon want to be able to put the warnings into various bins (e.g. Wcompat, which seems very very useful for library writers for the same reasons it's useful for GHC itself).

I'm still a bit baffled by the "x-" bit. It just seems like extra noise.

Or is there an (entirely implicit) suggestion that eventually we might want "y-" and "z-" prefixes, for some y and z?

Are you baffled by the x- appearing in the flags (-Wno-x-partial) or that they also appear in the pragmas as in {-# WARNING [x-partial] "foobar" #-}?

The motivation for the former is namespacing: If we don't keep custom warnings apart from those genuinely produced by the compiler, because else it’s unclear what to do with {-# WARNING [tabs] "hehe" #-}. (Last paragraph of section 2)

There is a suggestion to have other prefixes later maybe, to distinguish warning categories that should be on by default from those that should go to -Wextra or -Wall etc. (No entirely implicit, though, section 6.3).

The motivation for the latter is that some think it’s even more confusiong to have {-# WARNING [partial] "foobar" #-} but -Wno-x-partial, because now our mental models are confused whether partial or x-partial is the name of that warning category.

I agree that this x-foo business isn't particular aesthetic. Alternatives: * We could simply allow pragmas to use built-in warning categories. Maybe the library author has a good reason to group their warning with -Wwrong-do-bind or -Wdodgy-export (but it seems a rather dangerous and confusing direction.) * We could not require a prefix, but forbid any built-in warning categories (i.e. {-# WARNING [tabs] "foo" #-} is a error).

Then library code would have to rename their categories if they (accidentially) use a category name that a later GHC version starts to use themselves. * Library authors don't get to choose category names freely, but instead GHC maintains a list of allowed categories (starting with partial, but what else?). This would allow us to document their meaning precisely for consistency, and would also allow us to set their default severity (-Wdefault, -Wall etc.).

Do any of these alternatives sound better to you?

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Dienstag, dem 29.11.2022 um 10:14 +0000 schrieb Simon Marlow:

I'd like to see the pragma be `{-# WARNING [partial] head #-}` without the `x-` prefix, because 1. I'm not in favour of compulsory (and therefore redundant) extra syntax 2. I don't think there would be much confusion about which flag to use, because the flag is literally included in the warning/error message from the compiler.

looks like we are generally in favor of this proposal, while this particular shed’s wall color causes discussion. Arnaud suggested to use the namespace’d name of the category in both the flags and the pragma (i.e. [x-partial], [deprecations], to match -Werror=x-partial, -Werror=deprecations), which resonated with Adam, Richard and me. Simon PS was, however, baffled by this and Simon M voices a preference to only allow custom categories, without the the prefix, in pragmas ([partial]) to reduce noise and redundancy. Happy to hear more voices and accept with whatever the majority of voices said they’d prefer (without formal votes, doesn’t seem to be worth it), assuming nobody thinks either way is a showstopper. Minor point: Note that it’s not compulsory: The proposal (as it stands) does allow {-# WARNING [deprecations] -#}, which corresponds to, say,  -Werror=deprecations, _not_ -Werror=x-deprecations. If we’d do away with the explicit x- prefix in pragmas and add it implicitly, we should probably change Point 3 of the proposed change specification to not say that a pragma without category is treated like {-# WARNING [deprecations] #-}, but simply state that it’s then controlled by the (built-in, non x-’ed) “deprecations” category, even if the same effect cannot be achieved syntactically with an explicit category. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, Am Freitag, dem 09.12.2022 um 19:31 +0100 schrieb Joachim Breitner:

Am Dienstag, dem 29.11.2022 um 17:14 +0100 schrieb Joachim Breitner:

...

Happy to hear more voices and accept with whatever the majority of voices said they’d prefer (without formal votes, doesn’t seem to be worth it), assuming nobody thinks either way is a showstopper.

didn’t hear more on this issue. If silence continues for a few more days, I’ll accept it (in the current variant ({-# WARNING [x-partial] #-}), by popular vote).

accepted and merged! Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/