LazyList.fill and LazyList.tabulate aren't lazy in the head

[SethTisue]

for LazyList.fill, I would expect the same output in both cases here:

scala> LazyList.continually(println("hey!")).apply(4)
hey!

scala> LazyList.fill(5)(println("hey!")).apply(4)
hey!
hey!
hey!
hey!
hey!

and similarly for tabulate:

scala> import util.chaining._
import util.chaining._

scala> LazyList.from(0).map(_.tap(println)).apply(4)
4
res30: Int = 4

scala> LazyList.tabulate(5)(_.tap(println)).apply(4)
0
1
2
3
4
res32: Int = 4

perhaps there are other methods with this problem?

noticed in @paulp's gist: https://gist.github.com/paulp/fac614c6de23c10644a7af25f4ef96e4

tentatively assigning @NthPortal as this is a continuation of scala/scala#7000

---

methods to fix:

• fill
• tabulate

[paulp]

None of these terminate. If this is intended to be the forever replacement for Stream, I'd think that they would. YMMV.

(LazyList from 1 dropRight 1).head
(LazyList from 1).reverse.reverse.head
(LazyList from 1 takeRight 0)
(LazyList from 1 dropRight 0)

[NthPortal]

(LazyList from 1 dropRight 1).head can be fixed by scouting ahead
(LazyList from 1 takeRight 0) and (LazyList from 1 dropRight 0) can be fixed by checking for non-positive values

I'm not sure if I agree that I would expect (LazyList from 1).reverse.reverse.head to terminate, but I will think about it some more

[NthPortal]

In order to have (LazyList from 1).reverse.reverse.head terminate, you would need to have a special LazyList variant representing a reversed one, so that reversing that would return the original LazyList; however, I don't personally think that makes a lot of sense.

[paulp]

It makes enough sense that it already exists as a view:

scala> (LazyList from 1).view.reverse
res0: scala.collection.SeqView[Int] = View(?)

scala> res0.getClass
res1: Class[_ <: scala.collection.SeqView[Int]] = class scala.collection.SeqView$Reverse

But of course that doesn't work either.

scala> (LazyList from 1).view.reverse.reverse.head
[...]

[NthPortal]

I will agree that reverse shouldn't evaluate the elements (even though it has to evaluate all of the states in order to reverse it).

At the very least, reverse is documented as $willNotTerminateInf.

[SethTisue]

I suggest spinning off the reverse/dropRight/takeRight stuff to a separate ticket; it's separate.

returning to fill and tabulate:

at https://twitter.com/StefanZeiger/status/1030056916981096449 @szeiger wrote of fill that he thought "you can use side-effects to build consecutive elements. It only makes sense if they are evaluated in order"

@szeiger are you sure? it seems to me that the possibility of out-of-order evaluation of side-effects is everywhere with LazyList, given that there are countless paths by which you can evaluate the tail without evaluating the head, yet still decide to evaluate the head later on. for example:

scala> var counter = 0
counter: Int = 0

scala> LazyList.continually{counter += 1; counter}
res10: scala.collection.immutable.LazyList[Int] = LazyList(?)

scala> res10.tail.head
res11: Int = 1

scala> res10.take(5).toList
res12: List[Int] = List(2, 1, 3, 4, 5)

why should fill be different?

to impose order dependence, we offer e.g. LazyList.iterate:

scala> import util.chaining._
import util.chaining._

scala> val ll = LazyList.iterate(0)(_.tap(println) + 1)
ll: scala.collection.immutable.LazyList[Int] = LazyList(?)

scala> ll.tail.head
0
res15: Int = 1

scala> ll.take(5).toList
1
2
3
res16: List[Int] = List(0, 1, 2, 3, 4)

[SethTisue]

it would be worthwhile for LazyList's Scaladoc to clearly state that not only are both head and tail lazy, they are independently lazy; evaluating the tail neither necessarily evaluates nor necessarily discards the head.

[NthPortal]

The whole scaladoc probably needs to be revamped. I didn't touch it at all. I think I will tackle that last, after fixing all the other laziness problems.

Edit: or if someone else wants to, I won't stop them - it shouldn't conflict with the code

[NthPortal]

wrt fill (and continually): I'm not sure how I feel about whether or not tail should force evaluation of head or not.

tabulate on the other hand, should not evaluate head when it evaluates tail. I don't expect the element generating function to be side-effecting, since it takes in an index

[NthPortal]

@SethTisue do you mind if I broaden this issue to cover all factories/generators with laziness problems? (and the other issue can cover all methods on an instance of LazyList with laziness problems)