Re: [MirageOS-devel] Using Result instead of Option in libraries

[David Scott <scott.dj@xxxxxxxxx>]

On Fri, Oct 14, 2016 at 3:23 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

On 14 Oct 2016, at 15:11, Hannes Mehnert <hannes@xxxxxxxxxxx> 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: http://erratique.ch/software/rresult/doc/Rresult.html
>> - Lwt_result has a slightly different set of combinators https://github.com/ocsigen/lwt/blob/master/src/core/lwt_result.mli
>>
>> 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/types/runtime.lwt/m_infix.mli

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 =

end

```

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 too *)

```

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?

Cheers,

Dave

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel