Is there any way to get lazy int ranges in Kotlin?...

# codereview

[Michael Böiers]

Is there any way to get lazy int ranges in Kotlin? I’m currently writing code like (1..n).asSequence() and it’s really annoying that you always have to clutter the code with the asSequence() call to make it lazy (read: perform well). EDIT: Yes, that came across the wrong way … lazy evaluation isn’t always better. 🙂

[Michael Böiers]

I mean, one could build something like

fun Int.untilIncluding(t: Int) = (this..t).asSequence()

but 1.untilIncluding(n) is still a mouthful compared to 1..n …

[Michael Böiers]

Renamed it to fun Int.lazyRangeTo(t: Int) = (this..t).asSequence() , that’s actually not bad. Now if there only was syntactical support for it. Something like (1…n) 😉

[Mărcuţ Andrei]

Did you mean to

fun IntRange.lazyToRange() = (this.start..this.endInclusive).asSequence()

and then to

(1..10).lazyToRange()

?

[Paul Griffith]

You could borrow from python and have a top-level xrange(start: Int, stop: Int) 🤷

[rook]

Don’t forget to infix so it can be as pretty as

1 lazyToRange 10

😛

[Michael Böiers]

@Mărcuţ Andrei no, I meant to replace the .. operator, like Ben showed. 😊

[Michael Böiers]

Something like this:

infix fun Int.seqTo(to: Int) = (this..to).asSequence()
infix fun Int.seqUntil(to: Int) = (this until to).asSequence()

(1 seqTo 10).forEach { println(it) }

[Mărcuţ Andrei]

🤔 it’s nice that you found what you looked for 😉

[ephemient]

https://medium.com/@ajalt/benchmarking-kotlin-sequences-e06d8bb4011c don't just blindly use sequences everywhere

[Michael Böiers]

“Use them if lazyness matters”. What I said.

[ephemient]

that's not how I read your initial statement "you always have to clutter the code with the asSequence() call to make it lazy", but ok

[Michael Böiers]

Well, if you need to make it lazy then you have to clutter the code. At least that’s what I intended to say.

[Michael Böiers]

Here’s an example from an advent of code challenge btw, where the laziness changes the runtime from days to milliseconds. 🙂

private fun String.reactOne() = when {
    length < 2 -> this
    else -> 0.lazyRangeTo(length - 2)
        .filter { this[it] == this[it + 1].otherCase() }
        .map { withoutSubstring(it, 2) }
        .firstOrNull() ?: this
}

[Mărcuţ Andrei]

That only means the conclusions in the above article are accurate. Sequences could lead to over-engineering in most cases. Don’t abuse them. It’s nice to see the powerful syntax flexibility of Kotlin that enables us to use the language in our own way ☺️

[Michael Böiers]

So lazy evaluation is evil? Don’t tell Venkat 😉

[Michael Böiers]

I’m aware of the different arguments here. Yes, I think that lazy evaluation can be abused. In some cases it can lead to “clever” code which depends on the laziness too much, in a non-obvious way. Still, I think that my code snippet is not so terribly abusive. Strikes a good balance between performance and readability, in my humble opinion.

[Michael Böiers]

The consequence of avoiding (lazy) sequences in this use case would be imperative code. That would be both good and bad … it would perform even better (good), but it would be less readable (bad).

[ephemient]

thinking about it some more… IntRange is already lazy, it doesn't materialize the whole list of values, it doesn't even check that it has reasonable endpoints (there are almost as many distinguishable empty ranges as there are non-empty ranges).

[ephemient]

but because it is Iterable, many readily available operations are eager.

[ephemient]

asSequence() is typically how to spell "from this iterator or iterable, subsequent operations should be lazy"; you'd like a more concise way of expressing that?

[Michael Böiers]

Yes. I think my suggested seqTo extension function is already sufficient. Having specific syntax for it would be nice, but maybe also non-obvious.

[ephemient]

as a local extension, perhaps something like

object RangeToSequence {
    operator fun Int.rangeTo(Int): Sequence<Int>
    // etc.
}
inline fun <T> seq(builder: RangeToSequence.() -> T): T

seq { 1..n }.map {}.filter {}.etc() could look neat. but maybe too much extra relative to a simple infix fun.

[Michael Böiers]

Nice!

[Mărcuţ Andrei]

But it’s not worth to do it unless the iteration haves a chance at finishing earlier. Otherwise it’s a misleading syntactic sugar which only enables the least favorable performance on the most of the subsequent operations.