> On 14 Oct 2016, at 15:05, David Scott <scott...@gmail.com> wrote:
>
>
> On Fri, Oct 14, 2016 at 2:51 PM, Anil Madhavapeddy <a...@recoil.org> 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@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
