https://kotlinlang.org logo
#arrow
Title
# arrow
n

Nathan Bedell

07/27/2022, 1:48 AM
Are there any examples of implementing the
nullable
effect using the new Effect API (rather than the now deprecated one?). I am building what is essentially a modified version of
nullable
, so an example of
nullable
built with the new API would be very helpful. From what I can tell, it looks like currently (at least on main)
nullable
still uses the deprecated API.
s

simon.vergauwen

07/27/2022, 6:25 AM
Curious what your custom modified version is supposed to do? Also note that with context receivers, you don't need this extra boilerplate, and you could do something like this instead.
Copy code
typealias Null = Nothing?

context(EffectScope<Null>)
@OptIn(ExperimentalContracts::class)
public suspend fun <B> B?.bind(): B {
    contract { returns() implies (this@bind != null) }
    return this ?: shift(null)
  }

suspend fun main() {
  val example: String? = null

  effect<Null, String> {
     example.bind()
  }.orNull()
}
y

Youssef Shoaib [MOD]

07/27/2022, 8:59 AM
@simon.vergauwen speaking of which actually, any plans for Arrow to utilise context receivers in the nearby future? Perhaps in a separate artifact or something?
s

simon.vergauwen

07/27/2022, 9:04 AM
Yes, ideally we deprecate these more elaborate runtimes and custom types in favor of simple context receiver DSLs but we are blocked by the Kotlin compiler.. It's currently only available for JVM, and only experimental if you enable the compiler flag 😅 So even in a separate artefact it's only possible for JVM atm.
On that note, I want to start designing and planning Arrow 2.0. I created a first ticket here, https://github.com/arrow-kt/arrow/issues/2768 And some discussions have taken place already during the bi-weekly public Arrow meetings. (You can poke #arrow-contributors if you want an invite to those meetings, non-obligatory to join every 2 weeks). I dumped some of my thoughts here, https://github.com/nomisRev/kotlin-gists You can check some thoughts surrounding flattening Validated/Either and removing some other types and APIs here, https://github.com/nomisRev/kotlin-gists/blob/main/src/main/kotlin/arrow2/Either.kt And 2 new implementations for Schedule without emulating dependent types, https://github.com/nomisRev/kotlin-gists/blob/main/src/main/kotlin/Schedule.kt https://github.com/nomisRev/kotlin-gists/blob/main/src/main/kotlin/Sched3.kt
y

Youssef Shoaib [MOD]

07/27/2022, 9:33 AM
Ooooooo exciting! I don't wanna overload this thread, but I btw almost have a complete implementation for a value class version of Option that (almost never) boxes. I'm gonna make a PR probably today or something, just figuring out some details around Effect and EagerEffect. (More details on that later but it turns out preventing boxing of a nested Option is a bit more complicated than it seems at first sight, but I was able to work around that). But yeah hopefully that could potentially make it into Arrow 2.0 if deemed useful
s

simon.vergauwen

07/27/2022, 9:40 AM
Yes, that'd be great to discuss for Arrow 2.0. Looking forward to see your findings
s

stojan

07/27/2022, 11:25 AM
This file experiments with an
Either
implementation that exposes an API covering both Either and Either use-cases.
I guess it's a typo, Validated and Either
s

simon.vergauwen

07/27/2022, 11:47 AM
Yes, it is 😅
@stojan & @Youssef Shoaib [MOD] let's discuss further in #arrow-contributors if you have any feedback. To not pollute this thread any further. @Nathan Bedell can you let me know if the provided info above was sufficient to solve your doubts/issues? 🙏
n

Nathan Bedell

07/27/2022, 11:47 PM
@simon.vergauwen Thanks for the link. It's basically a new approach to defining a monad comprehension syntax for "Tools" in my Iodine library. I'm coming back to it after awhile and I have a few ideas of how to simplify/improve things. Basically a tool is an async function that can manipulate the UI (think a modal dialog) -- but to thread it all together in compose the API needs more to it than just a raw async function. Tools also have a notion of cancellation, hence the being a variant of the nullable syntax.
@simon.vergauwen Glancing over that code, I think that should be sufficient, but I'll let you know if I have any questions.
Also @simon.vergauwen, re: "without emulating dependent types" -- what's that about? I've messed around a bit with a HKT-like encoding of (limited) type level functions in Kotlin (I can cook up a gist of you'd like to see), so I'm curious if this emulation of dependent types alluded to here is similar.
s

simon.vergauwen

07/28/2022, 7:18 AM
Warning… it’s super ugly 😅
Schedule
has a dependent type
State
, but you don’t want to expose it from the
Schedule<Input, Output>
type because it is only related to the internal impl of a
Schedule
. So you have to split the public type, and the “implementation type”. https://github.com/arrow-kt/arrow/blob/005c417fcad6831cf44503cfd35d3672d9b1302f/ar[…]oroutines/src/commonMain/kotlin/arrow/fx/coroutines/Schedule.kt Then you can expose a synthetic constructor that allows for specifying the “dependent type” without exposing it from the
Schedule<Input, Output>
type. https://github.com/arrow-kt/arrow/blob/005c417fcad6831cf44503cfd35d3672d9b1302f/ar[…]oroutines/src/commonMain/kotlin/arrow/fx/coroutines/Schedule.kt It’s rather ugly, and I wouldn’t advise on using such patterns in Kotlin. The same can typically be achieved by leveraging different techniques, as done in the linked alternative encodings for
Schedule
. Which results in much nicer, and simpler code.
If you have any questions or doubts on how to implement the DSLs for the Iodine library I’d be happy to help 👍
29 Views