<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>This proposal is a good start, but it needs more fleshing out.</div><div><br></div><div>- What scopes are allowed to suppress over? For example, is it possible to suppress warnings for scopes other than a function (for example, within a case expression)? What about type declarations? Local declarations? In a type signature?</div><div><br></div><div>- Is there a way to control what warnings are suppressed? Presumably, a user would like to suppress only certain warnings in certain places.</div><div><br></div><div>- Your proposal contains motivation and examples. These are necessary parts of a proposal. But we also need a full specification of the feature, describing precisely the syntax (where, exactly, `SUPPRESS` is allowed) and semantics.</div><div><br></div><div>I hope this feedback is helpful!</div><div>Richard</div><br><div><div>On Dec 14, 2015, at 8:52 AM, Эдгар Жаворонков <<a href="mailto:edzhavoronkov@gmail.com">edzhavoronkov@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi devs!<div><br></div><div>I edited wiki page [1] with my proposal about more than week ago. <span style="font-size:12.8px">The main idea is that we mark functins with pragma and filter all warnings that it will throw. Although it is the question of bad design, i think users, who have to support old libraries will find this helpful.</span></div><div style="font-size:12.8px"><br></div><div><span style="font-size:12.8px">I don't know about suppressing specific kinds of warnings. I think, that it would be more precise to filter them in one place instead of many.</span></div><div><br></div><div>Can someone review it? Sorry for bothering, if any</div><div><br></div><div>[1] - <a href="https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas" target="_blank" style="font-size:12.8px">https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas</a></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>---</div>С уважением,<div>Жаворонков Эдгар</div><div><br></div><div>Best regards,</div><div>Edgar A. Zhavoronkov</div></div></div></div></div></div>
<br><div class="gmail_quote">2015-12-03 15:16 GMT+03:00 Ben Gamari <span dir="ltr"><<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Эдгар Жаворонков <<a href="mailto:edzhavoronkov@gmail.com">edzhavoronkov@gmail.com</a>> writes:<br>
<br>
> Hello devs!<br>
><br>
> I am trying to implement some kind of local warnings suppresion and i need<br>
> some help.<br>
><br>
> I want to use a pragma to mark functions so compiler won't throw warnings<br>
> from them. I defined my pragma in lexer, parser and added type signature in<br>
> HsBinds.hs. And i am stuck. I don't know what to do. What should i consider<br>
> doing further?<br>
><br>
</span>I think it would be helpful to focus on further elaborating the<br>
specification before we move into the implementation. There are still a<br>
number of open questions about the design that the wiki page doesn't yet<br>
address.<br>
<br>
For instance, you should explicitly specify,<br>
<br>
 * What are the identifiers that appear after the `SUPPRESS` token?<br>
<br>
 * What exactly does the pragma apply to? For instance, if I have a case<br>
   like,<br>
<br>
       hello :: Int -> Int<br>
       {-# SUPPRESS some-warning #-}<br>
       helloAgain :: Type -> AnotherType<br>
       hello = (+1)<br>
       helloAgain = error "42"<br>
<br>
   or even just<br>
       hello = (+1)<br>
       {-# SUPPRESS another-warning #-}<br>
       helloAgain = error "oops"<br>
<br>
   What do you expect to happen? The behavior of the pragma in both of<br>
   these cases should be unambiguously stated in the specification.<br>
<br>
 * An concrete use-case motivating the change (preferably with examples<br>
   showing how the proposed syntax would address the motivation)<br>
<br>
I know this sounds repetitive, but the act of writing down a proposal<br>
will help you immensely when you do move on to implementing your ideas.<br>
<br>
Thanks for your persistence.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
</blockquote></div><br></div>
_______________________________________________<br>ghc-devs mailing list<br><a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br></blockquote></div><br></body></html>