-
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
Restrict the existentially quantified monad in a Weaving
to be Sem r
#304
Comments
Your alternatives don't consider a |
So we would just keep |
I did try to implement a So yes, this is fixable by using the following as {-# LANGUAGE RoleAnnotations #-}
module Polysemy.Internal where
import Polysemy.Internal.Kind
type role Sem nominal nominal
data Sem (r :: EffectRow) (a :: *)
instance Functor (Sem r)
instance Applicative (Sem r)
instance Monad (Sem r) And then sticking a @TheMatten No, |
I'm wondering - is |
It doesn't have to be, but the weaving can really only be used once it is. Nevertheless, I'd hold off on removing the Edit: If you're suggesting |
@KingoftheHomeless Ah, there's e.g. |
I did an experiment to see if it is possible to restrict Weaving to force It doesn't work because the documented invariant about polysemy/src/Polysemy/Internal/Writer.hs Line 201 in 016c16f
m = Lazy.WriterT o m , so not a Sem . Similarly for State , where m = S.StateT s (Sem r') .
I think this brings into question the whole premise of this issue, and maybe something like #328 is a more workable approach. |
The existentially quantified monad in a Locking this "inner", invisible-to-the-outside-world If you're interested in carrying on, use the changed definition of |
Good point - we don't need to change both monad parameters. I had a go at only changing It still runs into problems with definitions like https://github.com/A1kmm/polysemy/blob/c76424e326f10ada3f7623dc2b79989b38cce6a0/src/Polysemy/State.hs#L255. In that code, |
It turns out the above problem was only because I made I have squashed all my changes into one commit (original series of commits still available here: https://github.com/polysemy-research/polysemy/compare/master...A1kmm:weavingdetails-sem-experiment?expand=1), and made PR #333. |
This has been addressed by #333. |
From the documentation for
Weaving
inPolysemy.Internal.Union
:Turns out that knowing that
m ~ Sem r0
can actually be relevant, since that meansm
is a monad, and that allows you to manipulate actions that you transform using the distributionweaveDistrib :: forall x. f (m x) -> n (f x)
.For a toy example, it would allow interpreting effects like these (which is not possible today):
Through the following:
For a more convincing example, this would allow us to write the following interpreter:
For the following effect, which completely encapsulates the power of the
MonadMask
type-class:To be more specific, this change allows for the interpretation of
GeneralBracket
in a similar way as in polysemy-research/polysemy-zoo#61.We want to change
Weaving
as follows:Part of the incurred refactoring is trivial:
The type signatures of
inj
/Using
needs to be updated.We need to modify combinators that (re)interpret/intercept effects such that they may make use of the fact that
m ~ Sem r
.For example,
interpretFinal
should have its type signature changed to:Here's a list:
interpret
/H
intercept
/Using
/H
reinterpret
/2
/3
/H
rewrite
transform
The greatest problem with this change is that it causesPolysemy.Internal
andPolysemy.Internal.Union
to become mutually recursive, which can't be trivially fixed. One way to fix this is to move the definition ofSem r
(and its instances) intoPolysemy.Internal.Union
, but is that really what we want? I'd love help/opinions on how to address this.Just use this as
Polysemy/Internal.hs-boot
:and stick an
import {-# SOURCE #-} Polysemy.Internal
intoPolysemy.Internal.Union
.There are several alternatives to implementing this change:
Instead of restricting the existentially quantified monad to be
Sem r
, restrict it to be an arbitrary monad.This neatly side-steps the issue of mutually recursive modules, but also means that
Weaving
will also carry around aMonad
dictionary. The performance impact of this is most likely unacceptable.Instead of restricting
m
to beSem r
in theWeaving
, have the effect do it.For example,
Zip
can instead be defined as follows:Which will prove that the existentially quantified monad is
Sem r
upon pattern matching onZip
.This works, but needing the effect to specify that
m ~ Sem r
strikes me as ugly.You can also conjure a semi-plausible scenario in which you'd like to create an interpreter for a higher-order effect that doesn't belong to you, but the interpreter you'd like to define needs to know that
m ~ Sem r
and the effect doesn't place that restriction.The text was updated successfully, but these errors were encountered: