-
Notifications
You must be signed in to change notification settings - Fork 2
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
Re-export ReleaseKey and ResourceCleanupException #5
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please split the CI part into a separate PR.
src/Effectful/Resource.hs
Outdated
|
||
-- | A variant of 'R.unprotect' adjusted to work in the 'Eff' monad. | ||
-- | ||
-- /Note:/ the @release@ action returned will run a clone of the environment it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will it? I don't know what unprotect
does, but I don't see cloneEnv
below (unlike in allocateEff
).
Also, is having es
and es'
correct here? Does it make sense to be able to run the returned action in a completely different stack?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will it? I don't know what
unprotect
does, but I don't seecloneEnv
below (unlike inallocateEff
).
You're right, it does not run in a cloned environment - at least not necessarily. I wrote the note with alloacteEff
in mind and there the release action is run in a cloned environment. I updated the note to be a bit clearer on that.
Also, is having
es
andes'
correct here? Does it make sense to be able to run the returned action in a completely different stack?
Yes, I think it makes sense. Consider the use case mentioned in the documentation of the unprotect
:
Unprotect resource from cleanup actions; this allows you to send resource into another resourcet process and reregister it there.
We don't now what the effect row of that other resourcet process looks like and it might (and probably will) be different from the one we are in when calling unprotectEff
.
I moved the CI part to #6. |
Also provide Eff versions of release and unprotect.
Fixes #2
I also updated the CI setup and added bindings for
release
andunprotect
.@arybczak Maybe we can cut a new release at this point?