Allow ambiguous types (with warning) by default

David Feuer david.feuer at gmail.com
Sun Dec 6 05:15:51 UTC 2015


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 <ekmett at gmail.com> 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 <david.feuer at gmail.com> 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 <ekmett at gmail.com> 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 <david.feuer at gmail.com>
>> > 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
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>> >
>
>


More information about the ghc-devs mailing list