Skip to content

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

Closed
bplommer wants to merge 7 commits into
typelevel:series/3.xfrom
bplommer:transform-deferred
Closed

Add dual-effect Queue constructors, expose methods to change effect type of SyncRef and AsyncDeferred without mapK#1889
bplommer wants to merge 7 commits into
typelevel:series/3.xfrom
bplommer:transform-deferred

Conversation

@bplommer

@bplommer bplommer commented Apr 6, 2021

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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
Copy Markdown
Contributor Author

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

@bplommer

bplommer commented Apr 12, 2021

Copy link
Copy Markdown
Contributor Author

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
Copy Markdown
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