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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> Andrew Martin <[email protected]> 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 > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
