OK, fine. Is there a way to make it an error, but keep checking the rest of the module? My goal is *get both messages if possible*, within a module. I'm not tied to any particular mechanism of doing so.
On Sun, Dec 6, 2015 at 12:13 AM, Edward Kmett <[email protected]> wrote: > If you aren't the one writing the code that can't be called you may never > see the warning. It'll be tucked away in a cabal or stack build log > somewhere. > > -Edward > > On Sun, Dec 6, 2015 at 12:06 AM, David Feuer <[email protected]> wrote: >> >> No, I want it to *warn* by default. If I write >> >> foo :: something that will fail the ambiguity check >> bar = something that uses foo in a (necessarily) ambiguous way >> >> the current default leads me to do this: >> >> 1. Attempt to compile. Get an ambiguity error on foo whose exact cause >> is hard for me to see. >> 2. Enable AllowAmbiguousTypes and recompile. Get an error on bar whose >> exact cause is completely obvious, and that makes it perfectly clear >> what I need to do to fix foo. >> 3. Fix foo, and disable AllowAmbiguousTypes. >> >> I'd much rather go with >> >> 1. Attempt to compile. Get an ambiguity *warning* on foo whose exact >> cause is hard for me to see, but also an error on bar whose exact >> cause is completely obvious, and that makes it perfectly clear what I >> need to do to fix foo. >> 2. Fix foo. >> >> Simple example of how it is currently: >> >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo >> >> <interactive>:14:12: >> Couldn't match expected type ‘F a’ with actual type ‘F a0’ >> NB: ‘F’ is a type function, and may not be injective >> The type variable ‘a0’ is ambiguous >> In the ambiguity check for the type signature for ‘foo’: >> foo :: forall a. Num a => F a >> To defer the ambiguity check to use sites, enable AllowAmbiguousTypes >> In the type signature for ‘foo’: foo :: Num a => F a >> >> Couldn't match what with what? Huh? Where did a0 come from? >> >> > :set -XAllowAmbiguousTypes >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo >> >> <interactive>:16:61: >> Couldn't match expected type ‘Int’ with actual type ‘F a0’ >> The type variable ‘a0’ is ambiguous >> In the expression: foo >> In an equation for ‘bar’: bar = foo >> >> Aha! That's the problem! It doesn't know what a0 is! How can I tell it >> what a0 is? Oh! I can't, because foo doesn't give me a handle on it. >> Guess I have to fix foo. >> >> I'd really, really like to get *both* of those messages in one go, >> with the first one preferably explaining itself a bit better. >> >> On Sat, Dec 5, 2015 at 11:51 PM, Edward Kmett <[email protected]> wrote: >> > So you are saying you want users to write a ton of code that happens to >> > have >> > signatures that can never be called and only catch it when they go to >> > try to >> > actually use it in a concrete situation much later? >> > >> > I don't really show how this would be a better default. >> > >> > When and if users see the problem later they have to worry about if they >> > are >> > doing something wrong at the definition site or the call site. With the >> > status quo it complains at the right time that you aren't going to sit >> > there >> > flailing around trying to fix a call site that can never be fixed. >> > >> > -Edward >> > >> > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer <[email protected]> >> > wrote: >> >> >> >> The ambiguity check produces errors that are quite surprising to the >> >> uninitiated. When the check is suppressed, the errors at use sites are >> >> typically much easier to grasp. On the other hand, there's obviously a >> >> lot >> >> of value to catching mistakes as soon as possible. Would it be possible >> >> to >> >> turn that into a warning by default? >> >> >> >> >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> [email protected] >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> > > > _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
