Malcolm, That is very clear and answers my question! Thanks for taking the time to explain that. Trevor On Sat, Mar 21, 2015 at 8:30 AM Malcolm Matalka <[email protected]> wrote:
> They a unit on success, but what about failure. > > Consider: > > type error1 = Bad1 | Bad2 > type error2 = Bad3 | Bad4 > > val foo : unit -> (unit, error1) Result.t > val bar : unit -> (unit, error2) Result.t > > What type does (>>=) have in order to make that work? > > On the other hand, if we do: > > type error1 = [> `Bad1 | `Bad2 ] > type error2 = [> `Bad3 | `Bad4 ] > > The error values will compose and ocaml will union the variants together > so the final type of: > > (foo () >>= fun () -> bar ()) is > > (unit, [> `Bad1 | `Bad2 | `Bad3 | `Bad4 ]) Result.t > > That is a quick explanation that may not make sense. > > > Trevor Smith <[email protected]> writes: > > > Malcolm, > > > > Thanks for your response. I think I am dense and am not quite > understanding > > your point. In the example you gave the foo and bar both take and return > > unit. Can you explain a bit more your point? > > > > Trevor > > > > On Sun, Mar 15, 2015 at 7:39 AM, Malcolm Matalka <[email protected]> > wrote: > > > >> The biggest reason is that it makes doing any monadic Result.t work > >> possible. Consider: > >> > >> foo () >>= fun () -> > >> bar () >>= fun () -> > >> Cohttp.something () >>= function > >> | Ok ... -> > >> | Error ... -> > >> > >> > >> If every one of those functions returned a regular variant, you would > >> not be able to compose them like that. > >> > >> Trevor Smith <[email protected]> writes: > >> > >> > Hello, > >> > > >> > I am curious to hear the design tradeoffs that were considered in > >> choosing > >> > polymorphic variants vs variants in the code.mli types. I haven't > really > >> > wrapped my head around why that decision was made, and am eager to > learn > >> > more about real world use of polymorphic variants. > >> > > >> > Thank you. > >> > > >> > Trevor > >> > _______________________________________________ > >> > MirageOS-devel mailing list > >> > [email protected] > >> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > >> >
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
