Come ragionare sulla sicurezza dello stack in Scala Cats / fs2?

Ecco un pezzo di codice dalla documentazione per fs2 . La funzione goè ricorsiva. La domanda è: come facciamo a sapere se è stack sicuro e come ragionare se qualche funzione è stack sicuro?

import fs2._
// import fs2._

def tk[F[_],O](n: Long): Pipe[F,O,O] = {
  def go(s: Stream[F,O], n: Long): Pull[F,O,Unit] = {
    s.pull.uncons.flatMap {
      case Some((hd,tl)) =>
        hd.size match {
          case m if m <= n => Pull.output(hd) >> go(tl, n - m)
          case m => Pull.output(hd.take(n.toInt)) >> Pull.done
        }
      case None => Pull.done
    }
  }
  in => go(in,n).stream
}
// tk: [F[_], O](n: Long)fs2.Pipe[F,O,O]

Stream(1,2,3,4).through(tk(2)).toList
// res33: List[Int] = List(1, 2)

Sarebbe anche sicuro per lo stack se chiamiamo goda un altro metodo?

def tk[F[_],O](n: Long): Pipe[F,O,O] = {
  def go(s: Stream[F,O], n: Long): Pull[F,O,Unit] = {
    s.pull.uncons.flatMap {
      case Some((hd,tl)) =>
        hd.size match {
          case m if m <= n => otherMethod(...)
          case m => Pull.output(hd.take(n.toInt)) >> Pull.done
        }
      case None => Pull.done
    }
  }

  def otherMethod(...) = {
    Pull.output(hd) >> go(tl, n - m)
  }

  in => go(in,n).stream
}

La mia risposta precedente qui fornisce alcune informazioni di base che potrebbero essere utili. L'idea di base è che alcuni tipi di effetti hanno flatMapimplementazioni che supportano direttamente la ricorsione dello stack - è possibile nidificare le flatMapchiamate in modo esplicito o attraverso la ricorsione nel modo desiderato e non traboccare lo stack.

Per alcuni tipi di effetti non è possibile flatMapessere stack-safe, a causa della semantica dell'effetto. In altri casi potrebbe essere possibile scrivere uno stack-safe flatMap, ma gli implementatori potrebbero aver deciso di non farlo a causa di prestazioni o altre considerazioni.

Sfortunatamente non esiste un modo standard (o addirittura convenzionale) per sapere se flatMapper un determinato tipo è stack-safe. Cats include tailRecMun'operazione che dovrebbe fornire una ricorsione monadica stack-safe per qualsiasi tipo di effetto monadico lecito, e talvolta guardare tailRecMun'implementazione che è nota per essere legale può fornire alcuni suggerimenti sul fatto che a flatMapsia stack-safe. Nel caso di Pullsembra che questo :

def tailRecM[A, B](a: A)(f: A => Pull[F, O, Either[A, B]]) =
  f(a).flatMap {
    case Left(a)  => tailRecM(a)(f)
    case Right(b) => Pull.pure(b)
  }

Questo tailRecMè solo recursing attraverso flatMap, e sappiamo che Pull's Monadesempio è lecito , che è abbastanza buona evidenza che Pull' s flatMapnon è in pila di sicurezza. L'unico fattore di complicazione qui è che l'istanza per Pullha un ApplicativeErrorvincolo Fche Pull's flatMapnon lo fa, ma in questo caso, che non cambia nulla.

Quindi l' tkimplementazione qui è stack-safe perché flatMapon Pullè stack-safe e lo sappiamo dal punto di vista tailRecMdell'implementazione. (Se scavassimo un po 'più in profondità, potremmo capire che flatMapè stack-safe perché Pullè essenzialmente un involucro per FreeC, che è calpestato .)

Probabilmente non sarebbe tremendamente difficile riscrivere tkin termini di tailRecM, anche se dovremmo aggiungere il ApplicativeErrorvincolo altrimenti inutile . Immagino che gli autori della documentazione abbiano scelto di non farlo per chiarezza e perché sapevano Pullche flatMapva bene.

Aggiornamento: ecco una tailRecMtraduzione abbastanza meccanica :

import cats.ApplicativeError
import fs2._

def tk[F[_], O](n: Long)(implicit F: ApplicativeError[F, Throwable]): Pipe[F, O, O] =
  in => Pull.syncInstance[F, O].tailRecM((in, n)) {
    case (s, n) => s.pull.uncons.flatMap {
      case Some((hd, tl)) =>
        hd.size match {
          case m if m <= n => Pull.output(hd).as(Left((tl, n - m)))
          case m => Pull.output(hd.take(n.toInt)).as(Right(()))
        }
      case None => Pull.pure(Right(()))
    }
  }.stream

Nota che non c'è ricorsione esplicita.

La risposta alla tua seconda domanda dipende dall'aspetto dell'altro metodo, ma nel caso del tuo esempio specifico, >>risulteranno solo più flatMaplivelli, quindi dovrebbe andare bene.

Per rispondere alla tua domanda più in generale, l'intero argomento è un disordine confuso in Scala. Non dovresti scavare in implementazioni come abbiamo fatto sopra solo per sapere se un tipo supporta la ricorsione monadica stack-safe o no. Convenzioni migliori sulla documentazione sarebbero di aiuto qui, ma sfortunatamente non stiamo facendo un ottimo lavoro. Potresti sempre tailRecMessere "sicuro" (che è ciò che vorrai fare quando F[_]è generico, comunque), ma anche allora ti fidi che l' Monadimplementazione sia lecita.

Per riassumere: è una brutta situazione tutt'intorno e in situazioni delicate dovresti assolutamente scrivere i tuoi test per verificare che implementazioni come questa siano sicure per lo stack.