[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: David Scott <scott.dj@xxxxxxxxx>
  • From: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • Date: Fri, 14 Oct 2016 15:44:18 +0100
  • Cc: "mirageos-devel@xxxxxxxxxxxxxxxxxxxx" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 14 Oct 2016 14:44:26 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=recoil.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=L8FLBGWRVrf3C1tFeATLIM7OdC2QA5yTVKzoUCruqknVMKcWAuz TJir94MI2y/6YfKSOLOOpUCFkOqsePaj3XALDipaQ1R+Hs61muZLMIbOQSmgNJe7 e8mK2uSK/rSHhF94uKEAc9zodwEelQbGlz6TeQMeTbD73dHJ72w3agy0=
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

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 


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

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.