Allow ambiguous types (with warning) by default
David Feuer
david.feuer at gmail.com
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>
More information about the ghc-devs
mailing list