https://kotlinlang.org logo
#arrow-contributors
Title
# arrow-contributors
p

pablisco

05/06/2021, 9:05 PM
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
Never mind, it didn’t like the “anonymous” instance. This seems to work 😎
I may use a interface to avoid leaking the Effect internal details 🤔
r

raulraja

05/07/2021, 8:11 AM
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.
p

pablisco

05/07/2021, 8:14 AM
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 🤞
s

simon.vergauwen

05/07/2021, 8:19 AM
@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)
s

simon.vergauwen

05/07/2021, 8:21 AM
I do really like the explicit
orNull
in the Kotlin API naming
This could be considered folding and/or reducing so... 🤔 Ye naming is hard 😅
p

pablisco

05/07/2021, 8:23 AM
partialReduceOrNull
?
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 🙂
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
s

simon.vergauwen

05/07/2021, 9:37 AM
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?
👍 1
p

pablisco

05/07/2021, 9:39 AM
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
s

simon.vergauwen

05/07/2021, 9:42 AM
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.
👌 1
💯 1
p

pablisco

05/07/2021, 10:44 AM
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 🤔
Open to suggestions here 🙂
2 Views