I’m trying to (miss)use the Effect/ API to make a partial reduce comprehension like I mentioned to <...

# arrow-contributors

[pablisco]

I’m trying to (miss)use the Effect/ API to make a partial reduce comprehension like I mentioned to @raulraja but I seem to get this compilation error blob thinking upside down I’m not 100% sure of what I’m doing 😅
cc @simon.vergauwen

[pablisco]

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

[pablisco]

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

[raulraja]

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.

[pablisco]

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 😎 I’ll try to add some docs and open a PR later today 🤞

[simon.vergauwen]

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

?

[pablisco]

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

[pablisco]

@simon.vergauwen 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)

[simon.vergauwen]

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

[simon.vergauwen]

This could be considered folding and/or reducing so... 🤔 Ye naming is hard 😅

[pablisco]

partialReduceOrNull?

[pablisco]

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 🙂

[pablisco]

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 🤔
Something like: Either<R, IterationFailure> may be better and we can always provide an extension to make it a Result

[simon.vergauwen]

It doesn't really make sense to have Either<X, R> 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?

[pablisco]

I was thinking that we can communicate where it failed to make it easier to debug 🤔 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

[simon.vergauwen]

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.

[pablisco]

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

[pablisco]

Open to suggestions here 🙂