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

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

[again raising the issue: could some mailing list admin please set the
reply-to to the list -- there's no need to send the message to the
individual and to the list!]

On 14/10/2016 15:23, Anil Madhavapeddy 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!
> 
> 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?

My experience (reading other people's code, see e.g. [0]) is that
overloading the syntax of bind is bad, since it is hard to comprehend
locally.

Certainly, pure libraries not using Lwt can easily reuse >>= and >|=,
but as soon as you depend on both Lwt.t and result, I'd prefer to have
new character sequences for the binds (and not numerous `let open ___
in`).  The >>=? and >>|? originate from Ashish' suggestion
(https://lists.xenproject.org/archives/html/mirageos-devel/2015-02/msg00019.html)
-- I'm open to any suggestions about the specific character sequences,
as long as we can agree on some.


hannes

0:
https://github.com/mirage/ocaml-fat/pull/47/files#diff-b81e9dab6cb4cea2ce4b2d50ffcd660dL159

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