VisibleTypeApplication and AllowAmbiguousTypes

[Richard Eisenberg]

Just to close the loop on this: I have made this change in GHC, and the implication will be dropped in time for 8.0.

Thanks,
Richard

On Mar 15, 2016, at 4:11 PM, Adam Gundry <adam at well-typed.com> wrote:

> On 15/03/16 14:53, Richard Eisenberg wrote:
>> 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.
> 
> Yes. I think the key point here is that TypeApplications is typically
> required at use sites, whereas AllowAmbiguousTypes is needed at
> definition sites.
> 
> AllowAmbiguousTypes is a heuristic: ambiguity can arise without it, and
> even before TypeApplications there were cases in which
> AllowAmbiguousTypes was necessary to permit polymorphic definitions that
> could be used unambiguously in some contexts. With TypeApplications, any
> definition can be used given a suitable context, but ambiguity is still
> a useful rule for deciding whether a definition is likely to lead to
> type inference trouble.
> 
> TL;DR I agree that we should drop the implication.
> 
> All the best,
> 
> Adam
> 
> 
>> Richard
>> 
>> On Mar 15, 2016, at 9:16 AM, Ben Gamari <ben at smart-cactus.org>
>> wrote:
>> 
>>> Andrew Martin <andrew.thaddeus at gmail.com> 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
> 
> 
> 
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs