for-comprehension

scala> val a = List(1,2) a: List[Int] = List(1, 2) scala> val b = List(3,4) b: List[Int] = List(3, 4) scala> val c = List(5,6) c: List[Int] = List(5, 6) scala> val d = List(7,8) d: List[Int] = List(7, 8) scala> (a,b,c).zipped.toList res6: List[(Int, Int, Int)] = List((1,3,5), (2,4,6)) Now: scala> (a,b,c,d).zipped.toList <console>:12: error: value zipped is not a member of (List[Int], List[Int], List[Int], List[Int]) (a,b,c,d).zipped.toList ^ I've searched for this elsewhere, including this one and this one , but no conclusive answer. I want to do the following or similar: for((itemA,itemB

Disclaimer: the code snippet below relates to one of ongoing Coursera courses. Let's consider it's posted just for a learning purpose and should not be used for submitting as a solution for one's homework assignment. As the comment below states, we need to transform a list of Futures to a single Future of a list. More than that, the resulting Future should fail if at least one of input futures failed. I met the following implementation and I don't understand it completely. /** Given a list of futures `fs`, returns the future holding the list of values of all the futures from `fs`. * The

When I use a val in a for-comprehension, I get the warning: warning: val keyword in for comprehension is deprecated despite the production in the syntax appendix of the spec. This suggests that when I do something like for (x <- xs; a = x) I'm not really introducing a variable, such as if I do something like for (x <- xs) yield { implicit val a = x; /* more */ } where, as usual, the brace starts a new scope where I can introduce a new val, or even a new implicit. What am I really doing with that a ? Am I consuming stack space? Heap? Some other kind of alias? som-snytt Like an ordinary val pat

I have a number of functions that return a future that is the result of a for comprehension, but i need to need to recover from some possible failures on the way out. The standard syntax seems to capture the for comprehension as an intermediate results like so: def fooBar(): Future[String] = { val x = for { x <- foo() y <- bar(x) } yield y x.recover { case SomeException() => "bah" } } The best alternative to I've found is to wrap the whole for comprehension in parentheses: def fooBar(): Future[String] = (for { x <- foo() y <- bar(x) } yield y).recover { case SomeException() => "bah" } This

In a for-comprehension, I can't just put a print statement: def prod (m: Int) = { for (a <- 2 to m/(2*3); print (a + " "); b <- (a+1) to m/a; c = (a*b) if (c < m)) yield c } but I can circumvent it easily with a dummy assignment: def prod (m: Int) = { for (a <- 2 to m/(2*3); dummy = print (a + " "); b <- (a+1) to m/a; c = (a*b) if (c < m)) yield c } Being a side effect, and only used (so far) in code under development, is there a better ad hoc solution? Is there a serious problem why I shouldn't use it, beside being a side effect? update showing the real code, where adapting one solution is

In Python, I can do something like this: lazy = ((i,j) for i in range(0,10000) for j in range(0,10000)) sum((1 for i in lazy)) It will take a while, but the memory use is constant. The same construct in scala: (for(i<-0 to 10000; j<-i+1 to 10000) yield (i,j)).count((a:(Int,Int)) => true) After a while, I get a java.lang.OutOfMemoryError , even though it should be evaluated lazily. Nothing's inherently lazy about Scala's for-comprehension; it's syntactic sugar* which won't change the fact that the combination of your two ranges will be eager. If you work with lazy view s of your ranges, the