Allow ambiguous types (with warning) by default
Simon Peyton Jones
simonpj at microsoft.com
Mon Dec 7 13:30:55 UTC 2015
| 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
More information about the ghc-devs
mailing list