Warning suppression pragmas

Howard B. Golden howard_b_golden at yahoo.com
Mon Oct 26 23:35:27 UTC 2015

On US TV, Archie Bunker said "Stifle!"


> On Oct 26, 2015, at 1:59 PM, Alexey Shmalko <rasen.dubi at gmail.com> wrote:
> Hi!
> I think SUPPRESS could be enough.
> Hope this helps
> On Mon, Oct 26, 2015 at 8:59 PM, Эдгар Жаворонков
> <edzhavoronkov at gmail.com> wrote:
>> Hi Ben!
>> Thanks for your feedback
>> I thought a little and fixed some in wiki page
>> In my opinion SUPPRESS_WARNINGS is not a real long name for pragma, but i
>> can't come up with whort name that clearly describes purpose of such pragma
>> =(
>> Your suggestions are really welcome)
>> ---
>> С уважением,
>> Жаворонков Эдгар
>> Best regards,
>> Edgar A. Zhavoronkov
>> 2015-10-26 19:45 GMT+03:00 Ben Gamari <ben at well-typed.com>:
>>> Эдгар Жаворонков <edzhavoronkov at gmail.com> writes:
>>>> Hello Richard!
>>>> Can you take a look at some sort of specification i wrote week ago?
>>>> I placed it here:
>>>> https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas
>>>> I can imagine only two use cases, and i'm not sure about correcteness of
>>>> it
>>> Thanks for writing this up!
>>> The specification is a good start but it really needs more detail. For
>>> instance, what syntactic elements do you want this pragma to apply to?
>>> Bindings? Expressions? Top-level definitions like classes, types, and
>>> instances? Any lexical scope?
>>> It would be nice if the use-cases you mention were a bit more concrete.
>>> It wouldn't hurt to mention particular warnings that you might imagine
>>> that this would be useful for.
>>> It would likely be useful to draw inspiration from some of the schemes
>>> used by other languages listed on the ticket (Rust and C# IIRC). It
>>> wouldn't hurt to draw attention to the similarities and differences to
>>> these other schemes in the proposal text.
>>> On a more bike-shed-y note, `SUPPRESS_WARNINGS` is arguably a bit on the
>>> long side.
>>> Personally I would prefer not to see the pragma be bracketed as you
>>> propose in your last example as its effect then becomes quite
>>> "non-local". This pragma should, in my opinion, be a tool of precision,
>>> used sparingly for well-understood reasons. Allowing bracketed regions
>>> makes it too easy for definitions to "sneak in" to the supressed region,
>>> hiding legitimate warnings. In the interest of keeping the proposal
>>> concrete and concise I would either remove this alternative or move it
>>> to a dedicated "Alternatives" section.
>>> I'm looking forward to seeing what becomes of this. You might consider
>>> submitting the next iteration of the proposal to the Haskell subreddit
>>> to get a few more eyes on it. Onwards!
>>> Cheers,
>>> - Ben
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

More information about the ghc-devs mailing list