Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Future's traverse shouldn't need to consume a stream before returning asynchronously #7718

Closed
scabug opened this issue Aug 4, 2013 · 3 comments
Closed

Future's traverse shouldn't need to consume a stream before returning asynchronously #7718

scabug opened this issue Aug 4, 2013 · 3 comments
Labels
blocker enhancement library

Comments

@scabug
Copy link

scabug commented Aug 4, 2013

Calling Future.traverse on a stream shouldn't need to need to consume the stream before returning a future.

Contrast the following, for example (using Scalaz 7 and the contrib applicative functor instance for futures):

import scala.concurrent._
import scala.concurrent.ExecutionContext.Implicits.global

def toFutureString(value: Int) = Future(value.toString)
val xs = Stream.from(0)

// Hangs.
val stdRes = Future.traverse(xs)(toFutureString)

import scalaz._, Scalaz._, scalaz.contrib.std._

// Returns immediately.
val scalazRes = xs traverse toFutureString

See this Stack Overflow question for more discussion.
@scabug
Copy link
Author

scabug commented Aug 4, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7718?orig=1
Reporter: Travis Brown (travisbrown)
Affected Versions: 2.10.2

@scabug
Copy link
Author

scabug commented Aug 8, 2013

Leif Warner (pdxleif) said:
The scalaz traverse on Streams seems to be waiting for completion of the prior future before beginning execution of the next future, e.g. forcing evaluation the next element on completion of the current future. Which I guess is useful, but seems like the same behavior that you'd get from folding over a strict list w/ .flatMapping on the Futures. I'm used to more parallel behavior from Applicative, but perhaps this way gives you the ability to short-circuit on the rest if a prior one fails?

@scabug scabug closed this as completed Aug 16, 2013
@scabug
Copy link
Author

scabug commented Aug 16, 2013

@som-snytt said:
Since this issue was an improvement, oughtn't the resolution read "Not an improvement"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
blocker enhancement library
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@scabug