Aha, that's because `:t` operates on expressions, and when a pattern
synonym is used as an expression the required and provided contexts are
merged into one. Makes sense.
/ Emil
Den 2016-05-26 kl. 20:59, skrev Emil Axelsson:
However, it seems that `:t` gives the wrong type:
*Main> :t AddP
Ah, excellent! Thank you!
However, it seems that `:t` gives the wrong type:
*Main> :t AddP
AddP :: (Num a, Eq a) => Exp a -> Exp a -> Exp a
This type is reported whether or not I include the (correct) signature
for `AddP`.
`:i` is correct though:
*Main> :i AddP
pattern AddP :: () =>
GHC 8.0 swaps the order of provided vs required contexts in a pattern synonym
signature. (7.10 was advertised as experimental). Thus:
pattern AddP :: () => (Num a, Eq a) => Exp a -> Exp a -> Exp a
Then it's fine
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glas
I have a problem where a pattern synonym doesn't provide the expected
type refinement in GHC 8.0.1.
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PatternSynonyms #-}
data Exp a
where
Num :: (Eq a, Num a) => a -> Exp a
Add :: (Eq a, Num a) => Exp a -> Exp a -> Exp a
pattern NumP a = Num a
pat
On Thu, May 26, 2016 at 5:14 AM, Peter wrote:
> Solving for everything but f, we get f :: T -> Int.
So TDNR happens for things in function position (applied to something).
> Solving for everything but f, we get f :: T -> Int.
So TDNR happens for things in argument position.
> May not be solvab
Thank you for feeding my thoughts. How would this do for a slightly more
detailed definition?
1. If the compiler encounters an ambiguous function, it will temporarily
give it the type a -> b, or the type declared in the signature if there is
one.
2. Type inference completes as normal.
3. If the in
