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

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

I don't have a strong opinion about whether it's `-Wx-partial` or something
else.

Cheers
Simon

On Mon, 21 Nov 2022 at 23:18, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/20221129/f040e12a/attachment-0001.html>