Allow ambiguous types (with warning) by default

Tue Dec 8 16:36:34 UTC 2015

Sure, I'll open the ticket. It may well turn out that there's a less
invasive way to accomplish my ultimate goal (more useful error messages for
ambiguous types) without allowing the cascade you're worried about. In

foo :: Num a => F a -> G a

Something more like the following would be much better than what we
currently get:

The type variable `a' in the type of `foo :: Num a => F a -> G a' is
ambiguous. This means that code attempting to use `foo' will not be able to
give it a signature determining `a'. In particular: `a' appears only as an
argument to the type families `F' and `G', which may not be injective.
Therefore a signature at the use site fixing `F a' and `G a' to particular
types will not fix `a' to a particular type.
On Dec 7, 2015 8:31 AM, "Simon Peyton Jones" <simonpj at microsoft.com> wrote:

> |  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151208/7f0bf1a3/attachment.html>