Allow ambiguous types (with warning) by default

[Simon Peyton Jones]

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

Yes it'd be possible.  A bit fiddly, but certainly possible.

Of course, doing so can lead to a cascade of other errors, but in this case you seem to actively want those follow-on errors.

Would you like to open a ticket with a few illustrative examples to motivate your proposal?

Simon

|  
|  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
|  >> >>
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fma
|  >> >> il.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7
|  >> >>
|  c01%7csimonpj%40064d.mgd.microsoft.com%7c572fb4db692644c7b2d408d2f
|  >> >>
|  dfc50bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tzknS1bYbEs2G
|  >> >> NPvXuu6o1st%2b2VMSTTmRSH1L%2f9BSsk%3d
|  >> >>
|  >> >
|  >
|  >
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c572fb4db6926
|  44c7b2d408d2fdfc50bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kYhH
|  Q00HzSxbbNyqFt2OmHWSpPTyxsbeJPCF1tDzAA0%3d