A modern programming language that makes developers happier.

kotlinlang

image.png

I’m trying to (~miss~)use the Effect/ API to make a partial reduce comprehension like I mentioned to <@U4UGS5FC7> but I seem to get this compilation error :blob-thinking-upside-down: I’m not 100% sure of what I’m doing :sweat_smile:
cc <@U0RM4EPC7>

Never mind, it didn’t like the “anonymous” instance. This seems to work :sunglasses:

I may use a interface to avoid leaking the Effect internal details :thinking_face:

based on the stacktrace you have in the first one you found a problem in the inliner in the ASM compiler module.
Can you reproduce it in 1.5 with IR on? In whatever case maybe worth reporting.

I’ll see if I can make an independent reproducible example. I’ll add it as a task on GH so I don’t forget or maybe someone can pick it up. Either way, I’m happy that I got it working :sunglasses:  I’ll try to add some docs and open a PR later today :crossed_fingers:

Cool, so this is like a DSL for `reduceOrNull` <https://docs.w3cub.com/kotlin/api/latest/jvm/stdlib/kotlin.collections/reduce-or-null>

?

<https://github.com/arrow-kt/arrow/issues/2394>

<@U0RM4EPC7> Is like `reduceOrNull` but with comprehensions for iterating/skipping elements of a list/iterable (gonna make a reversed one for Lists)

I’m still not sure about the name (the hardest thing in programming)

I do really like the explicit `orNull` in the Kotlin API naming

This could be considered _folding_ and/or _reducing_ so... :thinking_face: Ye naming is hard :sweat_smile:

I thought that the partial is appropriate as we could, potentially, not iterate the whole collection. Could also create a `partialFoldOrNull` to provide an accumulator :slightly_smiling_face:

Actually, thinking of it, we could have both `partialReduceOrNull` for `R?` and without the `orNull` with either a `kotlin.Result`, `Either` or `Validated` I’m not 100% sure which would be best. We don’t tend to use `kotlin.Result` as exceptions are heavy :thinking_face:
Something like: `Either&lt;R, IterationFailure&gt;` may be better and we can always provide an extension to make it a `Result`

It doesn't really make sense to have `Either&lt;X, R&gt;` over `R?` unless you have additional information you can share with the consumer about the error. Afaik here only 1 error can occur which is that you request more elements than are available, right?

I was thinking that we can communicate where it failed to make it easier to debug :thinking_face:  But maybe we can do it later on if there is a requirement. After all, we can see the original list and see how many items we have

Where it failed, so something like `data class ReductionFailure(val originalSize: Int, val requestedIndex: Int)`? That is definitely possible but it would also require more state/overhead inside the DSL since you need to keep track of how many times `next()` was called etc.

Yeah, totally that overhead for the happy path is probably enough to not warrant it :100: I’ll keep it simple :slightly_smiling_face:
I guess the other question would be whether to make it eager or allow suspension by default :thinking_face:

Open to suggestions <https://github.com/arrow-kt/arrow/pull/2396|here> :slightly_smiling_face: