A unification with the WARNING pragma looks like a good idea to me. I
The machinery sketched in #11219 seems like a good way to switch between
#11796: Warn about unwanted instances in a modular way -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11219 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: hvr (added) Comment: Replying to [comment:4 Lemming]: think I did not consider it, because currently warnings cannot be grouped. But if WARNINGs can be grouped we could re-use this capability for `instance` warnings. `WARNING`s can be grouped, actually: {{{#!hs hello = "hello" world = "world" {-# WARNING hello, world "Beware" #-} }}} But this is much easier for top-level identifiers, since they have clearly defined names. Instances, on the other hand, don't have a convenient shorthand for referring to them, so it's not clear to me how you could group them together at the top-level. I believe that due to the way GHC parses pragmas, it cannot know that a pragma is "next" to an instance, so you have to nest it inside the instance to make it clear that this pragma belongs to that particular instance. An alternative would perhaps be to specify the unique string for an instance with a separate pragma, e.g., {{{#!hs instance Foo Int where {-# INSTANCE_TAG FooInt #-} ... instance Foo Char where {-# INSTANCE_TAG FooChar #-} ... {-# WARNING FooInt, FooChar "Watch out" #-} }}} Then you could group together multiple instances within a single `WARNING` at the top level. the effect of hitting a warning. I agree! The difference here is that we're not elevating/suppressing warnings wholesale in this case, but rather configuring them on a tag-by- tag basis. Nonetheless, we'd need similar machinery to what #11219 needs.
For `instance`s the module name should not be part of the identifier. The definition of the instance can be anywhere in the package in a private module. This module can be renamed without even a minor version bump. But when I think about it, the same is true for function identifiers.
Indeed. In fact, there could be two different private modules in the same package that export two functions with the same name, or two instances with the same tag. I can't think of a better way to tell them apart, can you? Relying on the exact location is a bit dangerous, admittedly, but it's the best form of disambiguation I know of. Ideally, you wouldn't have to use `<package>:<module>` very much in the first place, but it'd be nice to have for the few cases where it matters. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11796#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler