How dangerous is AllowAmbiguousTypes when used with TypeApplications?

Question

How dangerous is the AllowAmbiguousTypes extension when used with the TypeApplications extension?

The GHC manual gives the following example of an ambiguous type:

class C a

f :: C a => Int
f = 3

This fails to compile when not using AllowAmbiguousTypes with the following message:

file.hs:8:6: error:
    • Could not deduce (C a0)
      from the context: C a
        bound by the type signature for:
                   f :: forall a. C a => Int
        at file.hs:8:6-15
      The type variable ‘a0’ is ambiguous
    • In the ambiguity check for ‘f’
      To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
      In the type signature: f :: C a => Int
  |
8 | f :: C a => Int
  |      ^^^^^^^^^^

With AllowAmbiguousTypes, it compiles correctly.

However, the following example fails to compile even with AllowAmbiguousTypes:

class C a

f :: C a => Int
f = 3

g :: C a => Int
g = f

It gives the following error when trying to compile it:

file.hs:12:5: error:
    • Could not deduce (C a0) arising from a use of ‘f’
      from the context: C a
        bound by the type signature for:
                   g :: forall a. C a => Int
        at file.hs:11:1-15
      The type variable ‘a0’ is ambiguous
    • In the expression: f
      In an equation for ‘g’: g = f
   |
12 | g = f
   |     ^

This can be written by enabling TypeApplications and writing it like the following:

class C a

f :: C a => Int
f = 3

g :: forall a. C a => Int
g = f @a

AllowAmbiguousTypes sounds scary, but based on the description in the GHC manual, it seems pretty benign, especially when used with TypeApplications.

It's not like AllowAmbiguousTypes is going to cause runtime errors, right?

This combination of AllowAmbiguousTypes and TypeApplications also seems to be used in some pretty popular packages, like constraints.

`AllowAmbiguousTypes` is completely “safe”, in the sense that it is perfectly sound, will not make the compiler diverge, and cannot lead to runtime errors, it was just mostly useless prior to the introduction of `TypeApplications`. The combination of the two is a perfectly reasonable thing. — Alexis King, Apr 06 '18 at 03:09
This question is inspired by an answer I received to another question that used both `AllowAmbiguousTypes` and `TypeApplications` to good effect: https://stackoverflow.com/a/49671162/3040129. — illabout, Apr 06 '18 at 03:11
I woulnd't mind if they both were turned on by default -- actually, I'd like that very much. Without them, we need additional `proxy a` arguments, which look hack-ish to me: why should I pass a runtime value which carries no information, only to tell the compiler that I want to use type `a`? That should be a compile-time argument, and now it can be if we use `foo @ a`. Ambiguous types are very good, once you have type applications. There is no downside to them, now. — chi, Apr 06 '18 at 09:02

score 4 · Accepted Answer · edited Apr 06 '18 at 15:20

4

Alexis King nailed it in her comment; it deserves to be elevated to the level of an answer.

AllowAmbiguousTypes is completely safe, in the sense that it is perfectly sound, will not make the compiler diverge, and cannot lead to runtime errors. It was just mostly useless prior to the introduction of TypeApplications. The combination of the two is a perfectly reasonable thing.

edited Apr 06 '18 at 15:20

duplode

33,731
7
79
150

answered Apr 06 '18 at 14:56

Daniel Wagner

145,880
9
220
380

How dangerous is AllowAmbiguousTypes when used with TypeApplications?

1 Answers1