-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conditional effects #281
Comments
In fact, this generalizes: try :: forall e r a. HasHas e r => (Member e r => Sem r a) -> Sem r (Maybe a)
try e =
case hasHas @e @r of
Has -> pure <$> e
Hasnt -> pure Nothing |
This kind of power can also be derived from class Concrete r where
checkMembership :: forall e. Typeable e => Has e r I'll look into it. Edit: Actually, I think that would need the more precise proof of #110, because with the current representation, you run into this problem (representing data Membership e r where
Membership :: MemberNoError e r => Membership e r
instance (Typeable e, Concrete r) => Concrete (e ': r) where
checkMembership :: forall e'. Typeable e' => Maybe (Membership e' (e ': r))
checkMembership = case eqT @e @e' of
Just Refl -> Just Membership
_ -> (\Membership -> Membership) <$> checkMembership @r @e'
Which follows from that the type system can't deduce that With |
Actually, #110 wouldn't help with this: you can't deduce sendUsing :: Elem r e -> e (Sem r) a -> Sem r a or subsumeUsing :: Elem r e -> Sem (e ': r) a -> Sem r a What a pain. Perhaps the second variant is good enough? |
Looks a little similar to what was being discussed here: #315 |
I just realized we can use the typeclass machinery to determine whether or not an effect exists in our stack. The machinery (with crap names is this):
and can be used thusly:
I'm not sure what to do with this, but it's pretty neat.
The text was updated successfully, but these errors were encountered: