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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 14 Oct 2016, at 15:36, David Scott <scott.dj@xxxxxxxxx> wrote:
> 
> 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?

Good point. To go over to the "overload the operators" camp despite my previous 
mail, I did remember that ppx_let supports arbitrary monadic and applicative 
syntax:

https://github.com/janestreet/ppx_let

The convention there seems to be to export a Let_syntax module that provides 
the appropriate monadic/applicative operators.

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