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

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

On 14/10/2016 15:08, Anil Madhavapeddy wrote:
> 
>> On 14 Oct 2016, at 15:05, David Scott <scott.dj@xxxxxxxxx> wrote:
>>
>>
>> On Fri, Oct 14, 2016 at 2:51 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>> We have quite a few base libraries that use the pattern of
>>>
>>> val foo_exn : ... -> 'a
>>> @raises
>>>
>>> val foo: ... -> 'a option
>>> Gobbles the exception and returns Some/None
>>>
>>> Should we take the Mirage3 opportunity to port libraries like Ipaddr to 
>>> using the Result type instead, so it would be
>>>
>>> val foo : ... -> ('a, [`Msg of string]) result
>>>
>>> instead, using the Result type?  That would let libraries use combinators 
>>> such as Rresult, and not gobble errors from parsing silently.  It would be 
>>> an incompatible API bump so we would need to bump all consumers of, e.g. 
>>> Ipaddr  http://docs.mirage.io/ipaddr/Ipaddr_unix.V4.html simultaneously.
> 
>> Personally I like the sound of this-- it's nice to use combinators to parse 
>> a more complicated structure and be able to emit something more useful than 
>> "None" as an error. Should we write a "recommended conventions" doc or wiki 
>> page to include things like `foo_exn` and `foo` examples above?
> 
> 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

hannes


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