<p dir="ltr">That gets into making the whole parser / renamer / type checker a bit more incremental, and while that would be awesome, and an excellent example of that user experience can be seen in the lean theorem prover, its certainly trickier to see how to realize it in Haskell because the order in the module of top level decls has no bearing on what may be a mutually recursive knot of definitions. </p>
<p dir="ltr">Likewise, while I definitely think that it's good to have the maximal set of independent type errors reported back, this is the same type error just deferred to a new location. Likewise, as ed notes, this would push a lot of errors out of libraries and into library clients , which just seems bad </p>
<div class="gmail_quote">On Dec 6, 2015 12:15 AM, "David Feuer" <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.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>
On Sun, Dec 6, 2015 at 12:13 AM, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
> If you aren't the one writing the code that can't be called you may never<br>
> see the warning. It'll be tucked away in a cabal or stack build log<br>
> 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>> wrote:<br>
>><br>
>> No, I want it to *warn* by default. If I write<br>
>><br>
>> foo :: something that will fail the ambiguity check<br>
>> bar = something 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 cause<br>
>> is hard for me to see.<br>
>> 2. Enable AllowAmbiguousTypes and recompile. Get an error on bar whose<br>
>> exact cause is completely obvious, and that makes it perfectly clear<br>
>> 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 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 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 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 it<br>
>> what a0 is? Oh! I can't, because foo doesn't give me a handle on 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>> wrote:<br>
>> > So you are saying you want users to write a ton of code that happens to<br>
>> > have<br>
>> > signatures that can never be called and only catch it when they go to<br>
>> > try to<br>
>> > actually use it in a concrete situation 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 if they<br>
>> > are<br>
>> > doing something wrong at the definition site or the call site. With the<br>
>> > status quo it complains at the right time that you aren't going to sit<br>
>> > there<br>
>> > flailing around trying to fix a call site that can never be fixed.<br>
>> ><br>
>> > -Edward<br>
>> ><br>
>> > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer <<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 the<br>
>> >> uninitiated. When the check is suppressed, the errors at use sites are<br>
>> >> typically much easier to grasp. On the other hand, there's obviously a<br>
>> >> lot<br>
>> >> of value to catching mistakes as soon as possible. Would it be possible<br>
>> >> to<br>
>> >> turn that into a warning by default?<br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> ghc-devs mailing list<br>
>> >> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>> >> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><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="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>