Skip to content

Suggestion: Add parFlatMapN #365

@TobiasRoland

Description

@TobiasRoland

Motivation

I really like flatMap.

I also really like parMapN on tuples.

I therefore suspect I'd really love a parFlatMapN

currently:

val helloF: F[String] = (someF, someOtherF).parMapN((a,b) => "hello")
val worldFF: F[F[String]] = (someF, someOtherF).parMapN((a,b) => "world".pure[F])
val worldF: F[String] = stringFF.flatten

what I'd love to have:

val helloF: F[String] = (someF, someOtherF).parMapN((a,b) =>"hello")
val worldF: F[String] = (someF, someOtherF).parFlatMapN((a,b) => "world".pure[F])

Is there another way to accomplish this than parFlatMapN

Yep, but I think it'd be quite nifty to have it.
The argument against is I suspect that you can just do .parMapN(..).flatten - it's not that much more code to look at - but wouldn't the same argument apply to most flatMap operations (you could just do .map(...).flatten)?

It came up in a $DAYJOB example that looked not-really-but-kind-of-sort-of like this (using cats-effects IO here for the sake of the example)

def ioEnrichOrAbsent(thing: Thing): IO[Option[Enriched]] = ???

val enriched: IO[List[Enriched]] = (ioAPICall, ioSomeOtherAPICall).parMapN {
   (a,b) => {
      val listOfThings: List[Thing] = getListToTraverse(a,b)
      listOfThings
         .parTraverse(ioEnrichOrAbsent)
         .map(_.flatten)
   }
}.flatten

... which, yes, in this simplified could be refactored this to be more legible in a myriad ways. But, I still think parFlatMapN would have made it more obvious than a flatten (especially because I'm already using .flatten for the List[Option[A]]` inside the parMapN, so there's a bit of mental gymnastics people have to do to realize which thing is being flattened and why)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions