(I'm not entirely familiar with the inner workings of Haskell's constraint solver so this could likely be a rookie question.)
When trying to use type application on GHC 8.0.1, as shown in the following sample code
{-# LANGUAGE KindSignatures, RankNTypes, ConstraintKinds, ScopedTypeVariables, TypeApplications #-}
module Test where
import Data.Constraint
test0 :: forall (b :: *) . (forall a . a -> Bool) -> b -> Bool
test0 g = g @b
test1 :: forall (c :: * -> Constraint) (b :: *) . (c b) => (forall a . c a => a -> Bool) -> b -> Bool
test1 g = g @b
it gives me the following errors
• Could not deduce: c0 b
from the context: c b
bound by the type signature for:
test1 :: c b => (forall a. c a => a -> Bool) -> b -> Bool
at Test.hs:9:10-101
• In the ambiguity check for ‘test1’
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature:
test1 :: forall (c :: * -> Constraint) (b :: *).
(c b) => (forall a. c a => a -> Bool) -> b -> Bool
and
• Could not deduce: c a
from the context: c b
bound by the type signature for:
test1 :: c b => (forall a. c a => a -> Bool) -> b -> Bool
at Test.hs:9:10-101
or from: c0 a
bound by the type signature for:
test1 :: c0 a => a -> Bool
at Test.hs:9:10-101
• In the ambiguity check for ‘test1’
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature:
test1 :: forall (c :: * -> Constraint) (b :: *).
(c b) => (forall a. c a => a -> Bool) -> b -> Bool
test0
works where there is no constraint involved, but test1
doesn't.
If you have TypeApplications
enabled, you should enable AllowAmbiguousTypes
too. If you do so, the error goes away.
The ambiguity check rejects definitions t
such that no t :: type
annotation could ever typecheck. For example:
test1 :: Show a => Int
test1 = 0
If we try to use test1
elsewhere in our program, we find that there's no way to resolve the Show a
constraint by way of ::
annotation. Therefore the ambiguity check rejects the definition itself.
Of course, with type applications the ambiguity check becomes meaningless (arguably, it should be turned off by default in this case), since test1 @type
is fine and completely determined whenever there is a Show type
instance available.
Note that this is not the same as the famous show . read
ambiguity. That still produces an error, with AllowAmbiguousTypes
too:
test2 = show . read
-- "ambiguous type variable prevents the constraint from being solved"
Operationally, values with c => t
types are just functions from c
-typed instances to t
. Just defining test1
is fine, since we can always define a constant function. However, in show . read
we need to supply instances as argument (or else there's no code to be run), and there's no way to resolve them. Using test1
without a type application would be similarly ambiguous.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With