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

Transfer Cont from @nomisrev to arrow #2661

Merged
merged 114 commits into from Feb 21, 2022
Merged

Transfer Cont from @nomisrev to arrow #2661

merged 114 commits into from Feb 21, 2022

Conversation

i-walker
Copy link
Member

@i-walker i-walker commented Feb 3, 2022

Thanks to @nomisRev proposal 🙌🏾
I've slightly changed the names from Cont to Effect and ContEffect to EffectScope, e.g.:

class DomainError(msg: String) 

context(CoroutineScope, EffectScope<DomainError>)
suspend fun program(): Int {
    val fa = async<Int> { shift(DomainError("error")) }
    val fb = async { delay(2000); 1 }
    return fa.await() + fb.await()
}

Feedback is welcome ☺️

Comment on lines +70 to +73
internal class Eager(val token: Token, val shifted: Any?, val recover: (Any?) -> Any?) :
ShiftCancellationException() {
override fun toString(): String = "ShiftCancellationException($message)"
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should use the same trick here as we do for Effect, so users have an escape hatch to differentiate between JobCanncellationException and ShiftCanncelationException when they have to in low-level niche use-cases.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added tests in EagerEffect and Effect for low-level use-cases

@@ -0,0 +1,202 @@
# Semantics of Structured Concurrency + Effect<R, A>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not the documentation we want, this was part of the design process/documentation.
What we want instead is the README.MD

I'm thinking we should make it part of the KDoc on top of Effect, and link the page to Effect as well.

Currently, a lot of users have a hard time understanding the difference between Effect and EagerEffect and when or why they should be using either { } vs either.eager { }. This is currently completely undocumented inside arrow-continuations/arrow.core.computations.

I think we should add proper documentation in this PR before we merge, otherwise, it's going to be dropped to the bottom of the backlog again.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've ported most of the Docs and still updating others, but the last commit can be reviewed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated most places I was aware of, can I get another review

@i-walker
Copy link
Member Author

I removed EagerEffect<R, A>.toEffect(): Effect<R, A>, because effect { } and eagerEffect { } can fold or bind() an EagerEffect value and it would introduce multiple paths of how to operate with this value doing something like toEffect().bind(), even though bind() is sufficient.

Copy link
Member

@nomisRev nomisRev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work @i-walker! Thanks for all the great effort moving this into Arrow 🥳 👏 👏 👏

Comment on lines +43 to +44
- title: arrow.core.continutions.Effect
url: /apidocs/arrow-core/arrow.core.continuations/-effect/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not blocking this PR but I think we should put Effect under extensions and data types because it's something we want to promote.

It's the new implementation of Arrow's most powerful feature "computation blocks", and offers polymorphic properties we didn't have before. If we can somehow reference from the Effect page that'd be awesome.

Not sure if we have to link EffectScope, and EagerEffectScope since those should be linked from the Effect * EagerEffect page.
We can put EagerEffect alongside Effect and get away with only 2 new entries on the page, instead of a new section with 4 sub-sections.

I can take a stab at this in a subsequent PR though. What do you think?

cc\ @arrow-kt/maintainers

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes sounds great too, it would be great if we could link EffectScope with EagerEffectScope and showing they cover similar signatures.
And rearranging it sounds super.

On that note now that we moved on from Data type + extension (aka implementation of a Type class) we might want to consider just having Data types and computations.

The few typeclasses we have left can also have a dedicated place, if necessary
Just as a note, though.

arrow-site/docs/_data/sidebar-fx.yml Outdated Show resolved Hide resolved
@@ -63,6 +63,7 @@ s [Coroutines Guide](https://kotlinlang.org/docs/coroutines-guide.html) on Kotli
- [Pure & Referentially Transparent Functions]({{ '/fx/purity-and-referentially-transparent-functions/' | relative_url }})
- [Kotlin's Std Coroutines package]({{ '/fx/coroutines/' | relative_url }})
- [Why suspend over IO monad]({{ '/effects/io/' | relative_url }})
- [Semantics of Structured Concurrency and Effect]({{ '/arrow/core/continuations/' | relative_url }})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idem. Arrow Core functionality.
We have a document already concerning Arrow Fx Coroutines & Structured Concurrency, no?
If we don't need to create a ticket to write one and add it to this documentation page.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have this, but it doesn't go as deep as Semantics of Structured Concurrency and Effect maybe we can create a ticket and I'd be happy to contribute it. Or help in whatever way

@@ -68,6 +68,7 @@ boilerplate and enable direct syntax including [monad comprehensions and computa
- [Kotlin's Std Lib Guide](https://kotlinlang.org/api/latest/jvm/stdlib/)
- [Pure & Referentially Transparent Functions]({{ '/fx/purity-and-referentially-transparent-functions/' | relative_url }})
- [Why suspend over IO monad]({{ '/effects/io/' | relative_url }})
- [Semantics of Structured Concurrency and Effect]({{ '/arrow/core/continuations/' | relative_url }})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we follow the changes suggested above, we should add Effect and EagerEffect to Extensions and data types above.

Can be done in subsequent PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes we can leave it as a task in a ticket regarding how/ or what we should show on the site

nomisRev and others added 4 commits February 21, 2022 20:06
Co-authored-by: Simon Vergauwen <nomisRev@users.noreply.github.com>
…ntinuations/EagerEffect.kt

Co-authored-by: Simon Vergauwen <nomisRev@users.noreply.github.com>
…ntinuations/Effect.kt

Co-authored-by: Simon Vergauwen <nomisRev@users.noreply.github.com>
@i-walker
Copy link
Member Author

i-walker commented Feb 21, 2022

Thanks for extensive review @nomisRev, learnt a lot 🤗

@i-walker i-walker merged commit 658b642 into main Feb 21, 2022
@i-walker i-walker deleted the is-effect branch February 21, 2022 20:19
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.

None yet

4 participants