Skip to content
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

Add dual-effect Queue constructors, expose methods to change effect type of SyncRef and AsyncDeferred without mapK #1889

Closed
wants to merge 7 commits into from

Conversation

bplommer
Copy link
Contributor

@bplommer bplommer commented Apr 6, 2021

The motivation for this is to be able to allocate resources in the form Resource[F, Thing[G]] where the same state needs to be accessed in G by the Thing but in F for the Resource.

I'll add tests and typeclass instances if this is approved in principle, and do something similar for Ref.

@bplommer bplommer marked this pull request as draft April 6, 2021 09:10
@bplommer bplommer marked this pull request as ready for review April 6, 2021 10:05
@bplommer bplommer force-pushed the transform-deferred branch from d75ecc8 to f248edb Compare April 6, 2021 11:37
@djspiewak
Copy link
Member

Interesting! Will need to think about this a bit… I can see the utility though.

@bplommer bplommer changed the title Expose methods to change effect type of AsyncDeferred without mapK Add dual-effect Queue constructors, expose methods to change effect type of SyncRef and AsyncDeferred without mapK Apr 12, 2021
@bplommer
Copy link
Contributor Author

After playing around with this some more, I've added a confirmed use case for this - dual-effect Queue constructors.

@bplommer
Copy link
Contributor Author

bplommer commented Apr 12, 2021

Actually, the previous comment is misleading - the transform methods aren't needed for a dual-effect queue constructor. Anyway, I'll leave this PR as is for now and maybe open a separate one to just add the dual-effect constructor.

@djspiewak
Copy link
Member

Given that we can now easily convert between SyncIO and IO, is this really still necessary? I'm trying to try to wrap my head around where this benefits us vs something simpler like mapK.

@djspiewak djspiewak closed this Jul 24, 2021
@bplommer bplommer mentioned this pull request Feb 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants