More efficient slidingN functions

[joroKr21]

We piggy-back on toIterable.
This is also an easy way to avoid stack overflow.

Fixes #4066

[armanbilge]

Can we add the example from #4066 as a test?

[joroKr21]

Can we add the example from #4066 as a test?

Where should I add this? FoldableSuite is kinda weird

[satorg]

Aside question: how come slidingN functions return List[TupleN] rather that F[TupleN] itself?

I mean, if F[_] is e.g. LazyList (which is still Foldable) then it will be enforced although it is not necessary to do for such a method.

[johnynek]

Foldable[F] is really basically ToList[F] to answer your question @satorg .

There is no methods to create an F[_] with Foldable[F], just take them apart.

[johnynek]

I approved, but I do think adding the test that caused a stack overflow would be good.

[satorg]

I'm just thinking – wouldn't Alternative be a better bet for sliding-like functionality eventually?

This is a question for the future of course – not related to this PR specifically.
This PR is great on its own )

[armanbilge]

Thanks for the quick fix :)

[johnynek]

@satorg I don't see a function like this in cats, but I think we could add it:

trait Alternative[F[_]] ... {
  def fromFoldable[G[_], A](ga: G[A])(implicit G: Foldable[G]): F[A] = {
    @tailrec def loop(lst: List[A], left: F[A]): F[A] =
      lst match {
        case a :: as => appendK(left, a)
        case Nil => left
     }

    loop(G.toList(ga), empty)
  } 
}

which we could override with more efficient implementations as needed (such as going in the reverse direction for building list, or using a List.newBuilder).

[satorg]

@johnynek what I really meant is that having both Foldable and Alternative available for F it could be possible to implement something like this:

def slidingN[F[_]: Alternative : Foldable, A](fa: F[A]): F[(A, ..., A)]

while preserving laziness for those F[_] which support it (i.e. LazyList).

What I was thinking about – there's combineEvalK available via Alternative which pretends to support laziness.
But in fact as for now combineEvalK does not support laziness for lazy collections, unfortunately.
Therefore, lazy-aware implementation would also require a FlatMap instance to shift combineK into "lazy" context:

  def lazySliding3[F[_], A](fa: F[A])(implicit FA: Alternative[F], FF: Foldable[F], FM: FlatMap[F]): F[(A, A, A)] = {
    val it =
      FF.toIterable(fa).iterator.sliding(3).withPartial(false)
        .map(_.toList).map { case a1 :: a2 :: a3 :: Nil => (a1, a2, a3) }

    def go(): F[(A, A, A)] = {
      FA
        .pure(Eval.later {
          if (it.hasNext)
            FA.prependK(it.next(), go())
          else
            FA.empty[(A, A, A)]
        })
        .flatMap(_.value) // this trick shifts all prependK into "lazy" context for lazy collections
    }

    go()
  }

Note: this is a "quick and dirty" implementation. It is not stack-safe for non-lazy collections.

[satorg]

The issue with combineEvalK I described here in Discord:
https://discord.com/channels/632277896739946517/632278570512678923/916869020534317076

I am not really sure it is the issue though – maybe it is an expected behavior )