Lwt: [discussion] extensions of lwt_result

[c-cube]

This issue should list the ways Lwt_result can become more useful.

• As already mentioned in #320, a sub-module for dealing with lists of results would help (with e.g. seq_l : ('a, 'e) result Lwt.t list -> ('a list, 'e) result Lwt.t and the likes)
• a add_ctx : string -> ('a, string) t -> ('a, string) t combinator for enriching the error message with surrouding context (recreating a kind of "stack trace" to give more context to the messages). Also, the format4-pendant of add_ctx.
• conversions between various styles of errors?
• seek inspiration from rresult

[hcarty]

:+1: for looking to rresult for inspiration. It's a wonderful library.

[brendanlong]

It would be really nice to have the Lwt_result.Infix operators available in Lwt too, like how Async has >>=? and >>|?. It's a little less useful in Lwt since presumably most people aren't using Or_error.t, but it's still nice if you're using string, exn, or polymorphic variant 'error types.

[aantron]

@brendanlong Perhaps the existing ones in Lwt_result.Infix should have had names that don't collide with Lwt.Infix?

[brendanlong]

I'm not sure. It seems nice to make all monads implement the same operators (although Lwt already doesn't match Core or Rresult), although realistically I think using the Lwt_result monad alone is pretty uncommon. There's also a related annoyance that >>= and >|= don't really cover everything you want (this is useful if you only have async function that potentially return errors and non-io functions that never return errors, but it's common to have non-io functions return errors and io functions that don't return errors..). So I'm not sure :\

[aantron]

Closing this for now due to staleness, please feel free to reopen if needed, or create new issues.