[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MirageOS-devel] CoHTTP Design: Polymorphic Variants
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 < mmatalka@xxxxxxxxx> 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 <trevorsummerssmith@xxxxxxxxx> 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 <mmatalka@xxxxxxxxx> 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 <trevorsummerssmith@xxxxxxxxx> 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
>> > MirageOS-devel@lists.xenproject.org
>> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
