<div dir="ltr"><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">
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). </div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I'm still a bit baffled by the "x-" bit. It just seems like extra noise.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Or is there an (entirely implicit) suggestion that eventually we might want "y-" and "z-" prefixes, for some y and z? <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 21 Nov 2022 at 12:55, Richard Eisenberg <<a href="mailto:lists@richarde.dev">lists@richarde.dev</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">I'm strongly in favor of this proposal, and I think that would remain true regardless of the shed colors.<br>
<br>
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.<br>
<br>
Richard<br>
<br>
> On Nov 16, 2022, at 2:16 PM, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
> <br>
> Dear all,<br>
> <br>
> Adam has submitted “WARNING pragmas with categories” for committee<br>
> consideration:<br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/541" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/541</a><br>
> <a href="https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/0000-warning-pragmas-with-categories.rst" rel="noreferrer" target="_blank">https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/0000-warning-pragmas-with-categories.rst</a><br>
> <br>
> I’m shepherding that one myself.<br>
> <br>
> WARNING pragmas can come with categories now:<br>
> {-# WARNING [partial] head "This is a partial function, …" #-}<br>
> <br>
> so that one can sensible group them and allow the user to silence the<br>
> warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just<br>
> like with the built-in warning categories.<br>
> <br>
> No language pragma is required (presumably since we are already in a<br>
> GHC-specific pragma).<br>
> <br>
> These custom warnings categories need to be prefixed with `x-` on the<br>
> command line to keep them separate from the built-in warnings. This is<br>
> a decision where I am inviting the committee to bikeshed:<br>
> * Do we really need a separator, or is it ok for library-defined <br>
> warnings to join a built-in category?<br>
> * Should it be used in syntax as well (WARNING [x-partial]) for easier <br>
> predictability and later extension to other prefixes (see below)?<br>
> <br>
> All these custom warning categories are part of the severity group<br>
> -Wdefault (on by default, not errors). I expect we eventually want to<br>
> give the programmer control over the severity (off by default, error by<br>
> default, part of -Wcompat, etc…), but it’s not immediately clear what<br>
> to do here, so we can add it latter (another optional field in the<br>
> pragma, a separate pragma, a naming convention like xe-foo, or<br>
> something else).<br>
> Please complain if you think this needs to be addressed here.<br>
> <br>
> Cheers,<br>
> Joachim<br>
> <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>
<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>