Open woehr opened 6 years ago
That's one of the limitations with the current implementation of Variant: when we have T a :<: '[X, T Int]
we don't infer a ~ Int
and similarly the other way around. It might be possible to help the type-checker with a compiler plugin but we would still have to deal with some ambiguous cases (e.g., T a :<: '[X, T Int, T Char, b]
should infer a ~ (Int, Char or something else depending on b)
).
As a workaround you can also use type applications:
bar :: T2 Bool
bar = C' @Bool (C True) (C True)
I see. Thanks for the explanation!
When using types like those of the example with pattern matching, type errors occur due to ambiguous type variables. For example, the following function does not work without -XScopedTypeVariables and the annotations in the pattern. I'm assuming this is the same issue, however type applications cannot be used in this situation. Is there a more convenient way of writing such a function? Also, this ghc ticket seems relevant https://ghc.haskell.org/trac/ghc/ticket/11350.
func :: EADT '[CF Char, C'F Char] -> Int
func (C (_ :: Char) ) = 1
func (C' _ (_ :: T1 Char)) = 2
Also, this ghc ticket seems relevant https://ghc.haskell.org/trac/ghc/ticket/11350.
Yes I'm waiting for this feature to come into GHC to remove type annotations in the pattern. If someone wants to write a GHC proposal for it, it would be great.
I'm trying to write a pattern for an EADT type that contains a less general, parameterised EADT type, but I receive the following ambiguous type variable error. I've reproduced the error in a minimum working example, below. In the example, the definition of bar causes the error.
Adding a type annotation (seen on
baz
) fixes the error. However, it seems obvious to me that the second argument toC'
should be aT1 Bool
. Thus I'm wondering if it's somehow possible to get the compiler to figure this out itself.This code produces the error above, but the annotation on baz makes it work: