<p dir="ltr">Sure, I'll open the ticket. It may well turn out that there's a less invasive way to accomplish my ultimate goal (more useful error messages for ambiguous types) without allowing the cascade you're worried about. In</p>
<p dir="ltr">foo :: Num a => F a -> G a</p>
<p dir="ltr">Something more like the following would be much better than what we currently get:</p>
<p dir="ltr">The type variable `a' in the type of `foo :: Num a => F a -> G a' is ambiguous. This means that code attempting to use `foo' will not be able to give it a signature determining `a'. In particular: `a' appears only as an argument to the type families `F' and `G', which may not be injective. Therefore a signature at the use site fixing `F a' and `G a' to particular types will not fix `a' to a particular type.</p>
<div class="gmail_quote">On Dec 7, 2015 8:31 AM, "Simon Peyton Jones" <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">| OK, fine. Is there a way to make it an error, but keep checking the<br>
| rest of the module? My goal is *get both messages if possible*, within<br>
| a module. I'm not tied to any particular mechanism of doing so.<br>
<br>
Yes it'd be possible. A bit fiddly, but certainly possible.<br>
<br>
Of course, doing so can lead to a cascade of other errors, but in this case you seem to actively want those follow-on errors.<br>
<br>
Would you like to open a ticket with a few illustrative examples to motivate your proposal?<br>
<br>
Simon<br>
<br>
|<br>
| On Sun, Dec 6, 2015 at 12:13 AM, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>><br>
| wrote:<br>
| > If you aren't the one writing the code that can't be called you may<br>
| > never see the warning. It'll be tucked away in a cabal or stack<br>
| build<br>
| > log somewhere.<br>
| ><br>
| > -Edward<br>
| ><br>
| > On Sun, Dec 6, 2015 at 12:06 AM, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>><br>
| wrote:<br>
| >><br>
| >> No, I want it to *warn* by default. If I write<br>
| >><br>
| >> foo :: something that will fail the ambiguity check bar = something<br>
| >> that uses foo in a (necessarily) ambiguous way<br>
| >><br>
| >> the current default leads me to do this:<br>
| >><br>
| >> 1. Attempt to compile. Get an ambiguity error on foo whose exact<br>
| >> cause is hard for me to see.<br>
| >> 2. Enable AllowAmbiguousTypes and recompile. Get an error on bar<br>
| >> whose exact cause is completely obvious, and that makes it<br>
| perfectly<br>
| >> clear what I need to do to fix foo.<br>
| >> 3. Fix foo, and disable AllowAmbiguousTypes.<br>
| >><br>
| >> I'd much rather go with<br>
| >><br>
| >> 1. Attempt to compile. Get an ambiguity *warning* on foo whose<br>
| exact<br>
| >> cause is hard for me to see, but also an error on bar whose exact<br>
| >> cause is completely obvious, and that makes it perfectly clear what<br>
| I<br>
| >> need to do to fix foo.<br>
| >> 2. Fix foo.<br>
| >><br>
| >> Simple example of how it is currently:<br>
| >><br>
| >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo<br>
| >><br>
| >> <interactive>:14:12:<br>
| >> Couldn't match expected type ‘F a’ with actual type ‘F a0’<br>
| >> NB: ‘F’ is a type function, and may not be injective<br>
| >> The type variable ‘a0’ is ambiguous<br>
| >> In the ambiguity check for the type signature for ‘foo’:<br>
| >> foo :: forall a. Num a => F a<br>
| >> To defer the ambiguity check to use sites, enable<br>
| AllowAmbiguousTypes<br>
| >> In the type signature for ‘foo’: foo :: Num a => F a<br>
| >><br>
| >> Couldn't match what with what? Huh? Where did a0 come from?<br>
| >><br>
| >> > :set -XAllowAmbiguousTypes<br>
| >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo<br>
| >><br>
| >> <interactive>:16:61:<br>
| >> Couldn't match expected type ‘Int’ with actual type ‘F a0’<br>
| >> The type variable ‘a0’ is ambiguous<br>
| >> In the expression: foo<br>
| >> In an equation for ‘bar’: bar = foo<br>
| >><br>
| >> Aha! That's the problem! It doesn't know what a0 is! How can I tell<br>
| >> it what a0 is? Oh! I can't, because foo doesn't give me a handle on<br>
| it.<br>
| >> Guess I have to fix foo.<br>
| >><br>
| >> I'd really, really like to get *both* of those messages in one go,<br>
| >> with the first one preferably explaining itself a bit better.<br>
| >><br>
| >> On Sat, Dec 5, 2015 at 11:51 PM, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>><br>
| wrote:<br>
| >> > So you are saying you want users to write a ton of code that<br>
| >> > happens to have signatures that can never be called and only<br>
| catch<br>
| >> > it when they go to try to actually use it in a concrete situation<br>
| >> > much later?<br>
| >> ><br>
| >> > I don't really show how this would be a better default.<br>
| >> ><br>
| >> > When and if users see the problem later they have to worry about<br>
| if<br>
| >> > they are doing something wrong at the definition site or the call<br>
| >> > site. With the status quo it complains at the right time that you<br>
| >> > aren't going to sit there flailing around trying to fix a call<br>
| site<br>
| >> > that can never be fixed.<br>
| >> ><br>
| >> > -Edward<br>
| >> ><br>
| >> > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer<br>
| <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>><br>
| >> > wrote:<br>
| >> >><br>
| >> >> The ambiguity check produces errors that are quite surprising to<br>
| >> >> the uninitiated. When the check is suppressed, the errors at use<br>
| >> >> sites are typically much easier to grasp. On the other hand,<br>
| >> >> there's obviously a lot of value to catching mistakes as soon as<br>
| >> >> possible. Would it be possible to turn that into a warning by<br>
| >> >> default?<br>
| >> >><br>
| >> >><br>
| >> >> _______________________________________________<br>
| >> >> ghc-devs mailing list<br>
| >> >> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
| >> >><br>
| <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fma" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fma</a><br>
| >> >> <a href="http://il.haskell.org" rel="noreferrer" target="_blank">il.haskell.org</a>%2fcgi-bin%2fmailman%2flistinfo%2fghc-<br>
| devs&data=01%7<br>
| >> >><br>
| c01%7csimonpj%<a href="http://40064d.mgd.microsoft.com" rel="noreferrer" target="_blank">40064d.mgd.microsoft.com</a>%7c572fb4db692644c7b2d408d2f<br>
| >> >><br>
| dfc50bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tzknS1bYbEs2G<br>
| >> >> NPvXuu6o1st%2b2VMSTTmRSH1L%2f9BSsk%3d<br>
| >> >><br>
| >> ><br>
| ><br>
| ><br>
| _______________________________________________<br>
| ghc-devs mailing list<br>
| <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
| <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h</a><br>
| <a href="http://askell.org" rel="noreferrer" target="_blank">askell.org</a>%2fcgi-bin%2fmailman%2flistinfo%2fghc-<br>
| devs%0a&data=01%7c01%7csimonpj%<a href="http://40064d.mgd.microsoft.com" rel="noreferrer" target="_blank">40064d.mgd.microsoft.com</a>%7c572fb4db6926<br>
| 44c7b2d408d2fdfc50bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kYhH<br>
| Q00HzSxbbNyqFt2OmHWSpPTyxsbeJPCF1tDzAA0%3d<br>
</blockquote></div>