VisibleTypeApplication and AllowAmbiguousTypes

Richard Eisenberg eir at
Tue Mar 15 14:53:53 UTC 2016

I'm happy to change the setting, but my logic was this: With -XTypeApplications, there are no ambiguous types. Of course, there may be types that are unambiguous locally but might be ambiguous in downstream modules that don't use -XTypeApplications, and this is what Andrew is (quite validly) getting at.


On Mar 15, 2016, at 9:16 AM, Ben Gamari <ben at> wrote:

> Andrew Martin <andrew.thaddeus at> writes:
>> I'm posting this because Richard said it would be the best place to raise
>> this issue. I know it's a little bit late in the GHC8 development process,
>> but I would like to get the idea out there.
>> To my knowledge, in GHC8, turning on VisibleTypeApplication will also turn
>> on AllowAmbiguousTypes. I think that a better behavior for most end users
>> would be to not have this happen.
>> I need AllowAmbiguousTypes turned on in modules where I want to declare
>> functions that are presently uncalled. At a call site though, I only need
>> VisibleTypeApplication, not both extensions. The only reason I bring this
>> up is because having AllowAmbiguousTypes on is usually bad. It makes it
>> possible to write functions that don't work, but you don't learn that until
>> you get to the call site. If I write libraries that require
>> VisibleTypeAppliaction to call certain functions, I don't want users
>> accidentally ending up turning on AllowAmbiguousTypes in their own code.
> It sounds reasonable to me to require that those defining
> functions to be used with type application enable AllowAmbiguousTypes.
> In my opinion we should avoid adding extension implications unless
> the extensions in question are essentially always used together and this
> doesn't appear to be true in the case of TypeApplications and
> AllowAmbiguousTypes.
> Cheers,
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

More information about the ghc-devs mailing list