Wondering if it might be a good idea to add some kind of `parRun { }` in the `Raise` context for so...

# arrow

[dave08]

Wondering if it might be a good idea to add some kind of parRun { } in the Raise context for something similar to what parZip does, that might be a pretty powerful idea... one could always use async { } from coroutines, but the handling of errors and bypassing things could maybe be simplified with parRun { }...

[simon.vergauwen]

What would parRun do in this case? 🤔

[dave08]

It would do the same as in parZip's lambdas (before the one that merges all the results.

[dave08]

and any failure (Left) could cancel all the other parRuns and clean up just like parZip.

[dave08]

It just makes parZip more "imperative"... like Raise does for flatMap on Either...

[simon.vergauwen]

Not entirely sure I got it, do you have a pseudo snippet in mind you could share? Sounds interesting

[dave08]

fun getHomeScreenContent() = either {
  val groups = api.getGroups(..).bind()

  groups.map {
    parRun { api.getGroupContent(it.id).bind() }
  }
}

[dave08]

Or:

fun getItemDetails() = either {
  val summary = parRun { api.getItemSummary(..).bind() }

  val details = 
    parRun { api.getItemDetails(...).bind() }
  
  Item(summary, details)
}

[dave08]

Very similar to the parZip/Map variants, but just more imperative.

[dave08]

Which could give the option to do certain things on certain conditions

[dave08]

fun getItemDetails() = either {
  val summary = parRun { api.getItemSummary(..).bind() }

  val details = if (summary...)
  
    parRun { api.getItemDetails(...).bind() }
  else
...
  
  Item(summary, details)
}

[dave08]

or any other such things, that parZip would be pretty ugly to use for.

[simon.vergauwen]

I think the second snippet is impossible. because how would details and summary run in parallel here if they immediately return the value so that's.

fun getItemDetails() = either {
  parZip(
    { api.getItemSummary(..).bind() },
    { api.getItemDetails(...).bind() }
  ) { summary, details -> Item(summary, details) }
}

The other snippet:

fun getHomeScreenContent() = either {
  val groups = api.getGroups(..).bind()

  groups.parMap {
    api.getGroupContent(it.id).bind()
  }
}

[dave08]

fun getItemDetails() = either {
  val summary = parRun { api.getItemSummary(..).bind() }

  val details = 
    parRun { api.getItemDetails(...).bind() }
  
  awaitParRun()

  Item(summary, details)
}

[dave08]

?

[simon.vergauwen]

So what would be the type of summary and details? It would need to be something like Deferred

[dave08]

Or:

fun getItemDetails() = either {
  val summary = parRun { api.getItemSummary(..).bind() }

  val details = 
    parRun { api.getItemDetails(...).bind() }
  
  Item(summary.bind(), details.bind())
}

where the binds on the parRun await their results

[dave08]

That would probably be even more flexible than awaitParRun() and Arrow users are already used the notion of bind() to get results..

[dave08]

I know the second example I gave above could be done with parMap, but when the logic gets more complex on exactly what to run in parallel while `map`ping, then it becomes more relevant to have another construct that's more imperative...

[dave08]

Or maybe it would be enough just to define a bind() on Deferred @simon.vergauwen? What do you think of the whole idea?

[dave08]

The possible problem with not having a separate construct like parRun would be when you need to handle neat cancellation when something raises... if you have parRun you can somehow keep track of the Deferred's that are being run (like accumulating their Jobs in some kind of list), so that they can be cancelled. Also, in either { } it would be cleaner not to have to use an extra nesting of coroutineScope { } to start the async's or have to manage a CoroutineScope manually...