taggedLookupKV :: forall t k v r a
. Members '[Tagged t (KVStore k v)] r
=> k
-> Sem r v
taggedLookupKV k = tag @t @(KVStore k v) (lookupKV @k @v k)
But if I try to add a second store (to say model the one updating the other), then this instantly fails to type check.
taggedLookupKV :: forall t t' k v r a
. Members '[Tagged t (KVStore k v), Tagged t' (KVStore k v)] r
=> k
-> Sem r v
taggedLookupKV k = tag @t @(KVStore k v) (lookupKV @k @v k)
• Could not deduce: Polysemy.Internal.Union.LocateEffect
(Tagged t0 (KVStore k4 v)) r
~ '()
from the context: Members
'[Tagged t (KVStore k4 v), Tagged t' (KVStore k4 v)] r
bound by the type signature for:
taggedLookupKV' :: forall k k2 k3 (t :: k) (t' :: k2) k4 v
(r :: [(* -> *) -> * -> *]) (a :: k3).
Members
'[Tagged t (KVStore k4 v), Tagged t' (KVStore k4 v)] r =>
k4 -> Sem r v
The type variable ‘t0’ is ambiguous
• In the ambiguity check for ‘taggedLookupKV’
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature:
taggedLookupKV :: forall t t' k v r a.
Members '[Tagged t (KVStore k v), Tagged t' (KVStore k v)] r =>
k -> Sem r v
Oh ok, so just to clarify if this is the whole prog
prog :: forall t t' k v r. Members '[Input k, Tagged t (KVStore k v), Tagged t' (KVStore k v)] r => Sem r ()
prog = do
a <- input @k
z <- tag @t @(KVStore k v) (existsKV @k @v a)
if z
then return ()
else
do
x <- tag @t' @(KVStore k v) (lookupKV @k @v a)
case x of
Nothing -> return ()
Just x' -> tag @t @(KVStore k v) (writeKV @k @v a x')
So I turn on ambiguous types then I just have to specify that whenever I use this, which is to be expected anyway.
Hi. I'm able to do this:
But if I try to add a second store (to say model the one updating the other), then this instantly fails to type check.
that's how hs type inference for type variables works
your
taggedLookupKV
doesn't have an argument which usest
ort'
so callers will be forced to manually specify what
t
andt'
are, usingTypeApplications
that's why ghc is asking you to enable
AllowAmbiguousTypes
because hs was originally designed with the thought of the user never having to do manual type annotations, and this breaks that "rule"
if you want to avoid
TypeApplications
, you can add aProxy t
argument, but usually people preferTypeApplications
because it's less noisy (imo)Oh ok, so just to clarify if this is the whole prog
So I turn on ambiguous types then I just have to specify that whenever I use this, which is to be expected anyway.
think so
oh and of note - I'm pretty sure the first one doesn't complain about ambiguous types only because of the plugin