[ghc-steering-committee] #451: WARNING pragma with category, Recommendation: accept

[Simon Peyton Jones]

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?highlight=warning#warnings-and-sanity-checking>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 <mail at joachim-breitner.de>
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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20221121/292e0209/attachment.html>