scalaz

问题 I have heard that iteratees are lazy, but how lazy exactly are they? Alternatively, can iteratees be fused with a postprocessing function, so that an intermediate data structure does not have to be built? Can I in my iteratee for example build a 1 million item Stream[Option[String]] from a java.io.BufferedReader , and then subsequently filter out the None s, in a compositional way, without requiring the entire Stream to be held in memory? And at the same time guarantee that I don't blow the

问题 This is a follow-up to my previous question. Suppose I need to find an XML node by path. I can write a function to get a child node by name import scala.xml.{Node => XmlNode} def child(name: String): XmlNode = Option[XmlNode] = _.child.find(_.label == name) I compose the child functions with kleisli; e.g. scala> val a = <a><a0><a1><a2/></a1></a0></a> a: scala.xml.Elem = <a><a0><a1><a2/></a1></a0></a> scala> val find01 = Kleisli(child("a0")) >=> Kleisli(child("a1")) findAB: scalaz.Kleisli

问题 This is a new version of my previous question We can define a parser as type Parser[A] = String => List[(A, String)] . The parser takes an input string and yields a sequence of pairs. Each pair consists of the parsing result and unconsumed part of the input. (See more in this article) Now we can define a parser pa , which succeeds if the 1st input character is a and fails otherwise. def symbol(c: Char): Parser[Char] = {s: String => s.toList match { case x :: xs if x == c => List((x, xs

问题 In Scalaz every Monad instance is automatically an instance of Applicative . implicit val listInstance = new Monad[List] { def point[A](a: => A) = List(a) def bind[A, B](fa: List[A])(f: A => List[B]) = fa flatMap f } List(2) <*> List((x: Int) => x + 1) // Works! Another example: Arrow is automatically a Profunctor . However, in Haskell I must provide an instance of Applicative for every Monad again and again. Is it possible to avoid this repetitive job? 回答1: It isn't currently possible,

问题 I'm trying to understand Monad Transformers in Scala by porting some examples from this tutorial by Dan Piponi: http://blog.sigfpe.com/2006/05/grok-haskell-monad-transformers.html I did a couple of easy ones: import Control.Monad.State import Control.Monad.Identity test1 = do a <- get modify (+1) b <- get return (a,b) test2 = do a <- get modify (++"1") b <- get return (a,b) go1 = evalState test1 0 go2 = evalState test2 "0" becomes: import scalaz._, Scalaz._ val test1 = for { a <- get[Int] _ <

问题 Recently I have come across this Scalaz code (e.g. https://github.com/scalaz/scalaz/blob/series/7.2.x/core/src/main/scala/scalaz/Functor.scala): def compose[G[_]](implicit G0: Functor[G]): Functor[λ[α => F[G[α]]]] = new CompositionFunctor[F, G] { implicit def F = self implicit def G = G0 } What is the meaning/purpose of the type expression inside the "Functor", i.e. λ[α => F[G[α]]]? Sofar, I have seen just type aliases like e.g. in http://like-a-boss.net/2014/09/27/type-lambda-in-scala.html

问题 This is a follow up to my previous question: Sequencing both Scalaz WriterT and Either with for-yield The following code block is an example of sequencing Future , Either and Writer using the EitherT and WriterT monad transformers; the following question is about how to subtly change the behaviour of that stack of transformers. import scalaz._, Scalaz._ class Example[F[_], L] (val logFn: (String) => L)(implicit val f: Monad[F], l: Monoid[L]) { type T = Throwable type EF[α] = EitherT[F, T, α]

问题 I'm trying to improve the type inference of the traverse_ function in the code below: import scala.language.higherKinds trait Applicative[AF[_]] { def ap[A, B](a: AF[A])(f: AF[A => B]): AF[B] def pure[A](a: A): AF[A] def fmap[A, B](a: AF[A])(f: A => B): AF[B] } def traverse_[AP[_]: Applicative, A](xs: Iterable[A])(f: A => AP[Unit]): AP[Unit] = { val ap = implicitly[Applicative[AP]] (xs :\ ap.pure(())) { (x, acc) => val apFunc = ap.fmap(f(x))(a => identity[Unit] _) ap.ap(acc)(apFunc) } }

问题 I am using scalaz7 in a project and sometimes I run into issues with imports. The simplest way get started is import scalaz._ import Scalaz._ but sometimes this can lead to conflicts. What I have been doing until now the following slightly painful process: work out a minimal example that needs the same imports as my actual code copy that example in a separate project compile it with the option -Xprint:typer to find out how the code looks after implicit resolution import the needed implicits

问题 In this recent Stack Overflow question, the author wanted to change a list of parsers of some type into a parser that returns lists of that type. We can imagine doing this with Scalaz's sequence for applicative functors: import scala.util.parsing.combinator._ import scalaz._ import Scalaz._ object parser extends RegexParsers { val parsers = List(1, 2, 3).map(repN(_, """\d+""".r)) def apply(s: String) = parseAll(parsers.sequence, s) } Here we take a list of three parsers that return lists of