Are there any examples of implementing the `nullab...

# arrow

[Nathan Bedell]

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.

[simon.vergauwen]

Hey @Nathan Bedell,

Here it's implemented for Effect, https://github.com/arrow-kt/arrow/blob/main/arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/continuations/nullable.kt.

[simon.vergauwen]

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.

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()
}

[Youssef Shoaib [MOD]]

@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?

[simon.vergauwen]

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.

[simon.vergauwen]

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

[Youssef Shoaib [MOD]]

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

[simon.vergauwen]

Yes, that'd be great to discuss for Arrow 2.0. Looking forward to see your findings

[stojan]

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

[simon.vergauwen]

Yes, it is 😅

[simon.vergauwen]

@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? 🙏

[Nathan Bedell]

@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.

[Nathan Bedell]

@simon.vergauwen Glancing over that code, I think that should be sufficient, but I'll let you know if I have any questions.

[Nathan Bedell]

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.

[simon.vergauwen]

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.

[simon.vergauwen]

If you have any questions or doubts on how to implement the DSLs for the Iodine library I’d be happy to help 👍