On Fri, Oct 14, 2016 at 3:23 PM, Anil Madhavapeddy <a...@recoil.org> wrote:
> On 14 Oct 2016, at 15:11, Hannes Mehnert <han...@mehnert.org> wrote:
> > On 14/10/2016 15:08, Anil Madhavapeddy wrote:
> >> Yeah, once we agree on the conventions :-) Once we have everything
> using Result.t, we also need to find the right set of combinators.
> >> - There is Rresult for basic Result.t handling:
> >> - Lwt_result has a slightly different set of combinators
> >> So I guess we need to decide if we publish an Rresult_lwt.t which lifts
> up "('a,'b) result" into an Lwt.t with the same API as Rresult otherwise.
> > Based on earlier discussion from January 2015, I put some combinators in
> > mirage-types.lwt (maybe they should live elsewhere)
> > https://github.com/hannesm/mirage/blob/network-error/
> Ah, missed those, thanks!
They do look useful :)
> Looks like we have a number of different conventions for the binds. Do we
> want to have the same set of operators with and without Lwt support (and
> open the Infix module locally as needed) or separate operators that be used
> alongside each other?
I'm curious what people recommend here -- I'm certainly open to adopting a
common convention even if it involves a bit of churn.
Initially I kept minting my own infix operators (like `>>*=` `>>|=`) but it
quickly got confusing for me and I probably didn't name them uniformly
across projects. Recently I've stuck to `>>=` and have put different ones
in different modules like this:
module LwtResult = struct
let (>>=) m f =
and now my code looks like (sometimes with extra newlines, but I don't have
strong opinions about that)
let open Lwt.Infix in
f () >>= fun () ->
let open LwtResult in
g () >>= fun () ->
Lwt.return (Result.Ok ()) (* possibly should define `return` in the module
Part of my rationale for using the same bind was a hope that one day
modular implicits might automatically choose the right version and I could
lose the `let open` but maybe this isn't possible?
MirageOS-devel mailing list