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 <b...@well-typed.com>: > Эдгар Жаворонков <edzhavoron...@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs