VisibleTypeApplication and AllowAmbiguousTypes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

VisibleTypeApplication and AllowAmbiguousTypes

Andrew Martin
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.

--
-Andrew Thaddeus Martin

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: VisibleTypeApplication and AllowAmbiguousTypes

Ben Gamari-2
Andrew Martin <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VisibleTypeApplication and AllowAmbiguousTypes

Richard Eisenberg-2
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.

Richard

On Mar 15, 2016, at 9:16 AM, Ben Gamari <[hidden email]> wrote:

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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: VisibleTypeApplication and AllowAmbiguousTypes

Adam Gundry-2
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 <[hidden email]>
> wrote:
>
>> Andrew Martin <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: VisibleTypeApplication and AllowAmbiguousTypes

Richard Eisenberg-2
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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>
>>> Andrew Martin <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: VisibleTypeApplication and AllowAmbiguousTypes

Joachim Breitner-2
Hi Richard,

along with this or some other change it seems you broke the test suite
when run with DEBUG:

T2478.hs:1:41: warning:
    -XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language.
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.1.20160321 for x86_64-unknown-linux):
        ASSERT failed!
  CallStack (from HasCallStack):
  assertPprPanic, called at compiler/typecheck/TcType.hs:931:47 in ghc:TcType
  t_ap0

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


*** unexpected failure for T2478(normal)

at least according to travis:
https://s3.amazonaws.com/archive.travis-ci.org/jobs/117548750/log.txt

Greetings,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VisibleTypeApplication and AllowAmbiguousTypes

Richard Eisenberg-2
Thanks for the heads up. I've pushed my fix to wip/rae and am waiting for Travis to give me the OK.

Richard

On Mar 21, 2016, at 7:05 PM, Joachim Breitner <[hidden email]> wrote:

> Hi Richard,
>
> along with this or some other change it seems you broke the test suite
> when run with DEBUG:
>
> T2478.hs:1:41: warning:
>     -XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language.
> ghc-stage2: panic! (the 'impossible' happened)
>   (GHC version 8.1.20160321 for x86_64-unknown-linux):
> ASSERT failed!
>   CallStack (from HasCallStack):
>   assertPprPanic, called at compiler/typecheck/TcType.hs:931:47 in ghc:TcType
>   t_ap0
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
>
> *** unexpected failure for T2478(normal)
>
> at least according to travis:
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/117548750/log.txt
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   [hidden email]https://www.joachim-breitner.de/
>   XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: [hidden email]
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs