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
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