is there a straightforward way to set up an Aff (Either x a) such that if I'm doing them in parallel via parSequence, I'll either get a Right (t a) or a Left x with all the non-completed affs canceled?
That's an interesting question. I can't think of a nice solution.
Usually, I'd just wrap everything in a timeout as described here, but that may not accomplish what you want.
Does your use case involve something that may fail quickly, along with other stuff that takes a while to succeed? For that situation, I'd split things up into two parallel sections, with the quickly-failing stuff scheduled first. Unfortunately, that's not the most elegant solution.
If you can wait for the other affs to finish after the first failure (and don't need the active cancellation) then it's straightforward to write something that returns Right (t a) / Left x.
I think active cancellation will require a forkAff / joinFiber / killFiber strategy, but you might be able to write a generic solution and then contribute it to the library.
hmm. I'm making a front-end framework heavily inspired by elm, and I like how elm tasks work (as long as they're extended to be parallelizable), and I keep flip flopping on whether or not I should use aff or use my own async code, but whichever I choose, I want something where I can go
parSequence[task1,task2,task3]
and get an array of results or just a singular error (with all pending tasks canceled). I think I've accomplished this with my own code (although I'm not to happy with how it looks at the moment and still working on it) and I haven't quite got it to work trying to wrap Aff (Either x a). Elm's Task, in case you're not aware, is basically an either built into some async capability, representing success or failure - it looks like Task x a
is there a straightforward way to set up an
Aff (Either x a)
such that if I'm doing them in parallel viaparSequence
, I'll either get aRight (t a)
or aLeft x
with all the non-completed affs canceled?That's an interesting question. I can't think of a nice solution.
Usually, I'd just wrap everything in a timeout as described here, but that may not accomplish what you want.
Does your use case involve something that may fail quickly, along with other stuff that takes a while to succeed? For that situation, I'd split things up into two parallel sections, with the quickly-failing stuff scheduled first. Unfortunately, that's not the most elegant solution.
If you can wait for the other affs to finish after the first failure (and don't need the active cancellation) then it's straightforward to write something that returns
Right (t a)
/Left x
.I think active cancellation will require a
forkAff
/joinFiber
/killFiber
strategy, but you might be able to write a generic solution and then contribute it to the library.hmm. I'm making a front-end framework heavily inspired by elm, and I like how elm tasks work (as long as they're extended to be parallelizable), and I keep flip flopping on whether or not I should use aff or use my own async code, but whichever I choose, I want something where I can go
and get an array of results or just a singular error (with all pending tasks canceled). I think I've accomplished this with my own code (although I'm not to happy with how it looks at the moment and still working on it) and I haven't quite got it to work trying to wrap
Aff (Either x a)
. Elm'sTask
, in case you're not aware, is basically an either built into some async capability, representing success or failure - it looks likeTask x a
Aff
also has built-in error handling, but you need to wrap everything in anattempt
ortry
. https://pursuit.purescript.org/packages/purescript-aff/5.1.2/docs/Effect.Aff#v:attemptAnd then you'll also need
throwError
within the tasks. But I agree that this is not as straightforward as what Elm offers.but that limits you to a single
Error
type, meant for JS exceptions. I would like to have the error type be anything.