[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Using Result instead of Option in libraries
> 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. Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |