On 18 Oct 2016, at 15:01, Richard Mortier wrote:
>
> On 18 October 2016 at 15:00, Daniel Bünzli
> wrote:
>> On Tuesday 18 October 2016 at 15:41, Richard Mortier wrote:
>>> Sorry-- not familiar enough with the terminology. Any chance one of
>>> you could point to an example of using "inclusion r
On 18 October 2016 at 15:00, Daniel Bünzli wrote:
> On Tuesday 18 October 2016 at 15:41, Richard Mortier wrote:
>> Sorry-- not familiar enough with the terminology. Any chance one of
>> you could point to an example of using "inclusion rather than union"
>> please?
>
> type err = [ `Sub of Sub.err
On Tuesday 18 October 2016 at 15:41, Richard Mortier wrote:
> Sorry-- not familiar enough with the terminology. Any chance one of
> you could point to an example of using "inclusion rather than union"
> please?
type err = [ `Sub of Sub.err | `Other | ... ]
vs
type err = [ Sub.err | `Other | ..
On 18 October 2016 at 14:24, Ashish Agarwal wrote:
> On Tue, Oct 18, 2016 at 4:38 AM, Daniel Bünzli
> wrote:
>
>> I think you should transform your errors according to your level of
>> abstraction as much as you do with your values.
>
> That's a good goal.
Yes; I think it fits very well with the
On 18 Oct 2016, at 14:24, Ashish Agarwal wrote:
>
> On Tue, Oct 18, 2016 at 4:38 AM, Daniel Bünzli
> wrote:
>
> I think you should transform your errors according to your level of
> abstraction as much as you do with your values.
>
> That's a good goal.
>
> Also using inclusion (by tagging
On Tue, Oct 18, 2016 at 4:38 AM, Daniel Bünzli
wrote:
I think you should transform your errors according to your level of
> abstraction as much as you do with your values.
That's a good goal.
> Also using inclusion (by tagging an error subset) rather than union for
> errors reported by subsys
On Monday 17 October 2016 at 22:49, Ashish Agarwal wrote:
> That's an interesting proposal. So you throw away the precision at some
> point. It seems a shame, but maybe that's good enough to get most of the
> value.
I think you should transform your errors according to your level of abstract
On Mon, Oct 17, 2016 at 4:41 PM, Daniel Bünzli
wrote:
As I said, monadic join.
>
I wasn't sure if that would cover the patterns that arise. Perhaps it does.
propagated to more generic error data types to the top level or to a
> logging point.
That's an interesting proposal. So you throw away
On Monday 17 October 2016 at 21:40, Ashish Agarwal wrote:
> True, these are even more precise, but the types are getting even more hairy
> now. Are there good combinators that help you anymore, or do we end up doing
> a lot of explicit match cases.
As I said, monadic join.
> I agree that good
On Mon, Oct 17, 2016 at 3:18 PM, Daniel Bünzli
wrote:
You want to make a clear distinction between the errors of the bracket and
> those of the client function (especially if these end up having overlapping
> cases) so you rather want either:
>
> 1) string -> f:(t -> 'a) -> ('a, [> err]) result
>
On Friday 14 October 2016 at 18:03, Ashish Agarwal wrote:
> With this style, you end up wanting to define a function like:
>
> val with_file :
> string ->
> f : (t -> (‘a, ‘b) Result.t ->
> (‘a, [> err | ‘b]) Result.t
Not really. You want to make a clear distinction between the errors of the
br
On Mon, Oct 17, 2016 at 10:53 AM, Richard Mortier <
richard.mort...@cl.cam.ac.uk> wrote:
> What was your experience here? Why *would* one force a closed type?
>
First, a terminology correction. What I was calling a "closed" variant is
actually an "exact" variant. A "closed" variant is of the for
Hi Ashish; Thanks for this mail, very useful! A couple of (naive!)
queries/comments inline.
On 14 October 2016 at 17:03, Ashish Agarwal wrote:
> Using polymorphic variants for the error type poses some challenges. Here
> are some things to think about. (The following code assumes `open Async.Std`
On 10/14/2016 11:03 AM, Ashish Agarwal wrote:
Using polymorphic variants for the error type poses some challenges.
Here are some things to think about. (The following code assumes `open
Async.Std` because it already has the necessary combinators).
Error Unification
# let x = return (Error `Ba
Using polymorphic variants for the error type poses some challenges. Here
are some things to think about. (The following code assumes `open
Async.Std` because it already has the necessary combinators).
Error Unification
# let x = return (Error `Bad);;
val x : ('a, [> `Bad ]) Result.t Deferred.t =
On 14/10/2016 15:44, Anil Madhavapeddy wrote:
> On 14 Oct 2016, at 15:36, David Scott wrote:
>>
>> Looks like we have a number of different conventions for the binds. Do we
>> want to have the same set of operators with and without Lwt support (and
>> open the Infix module locally as needed) or
On 14 October 2016 at 15:36, David Scott wrote:
>> Looks like we have a number of different conventions for the binds. Do we
>> want to have the same set of operators with and without Lwt support (and
>> open the Infix module locally as needed) or separate operators that be used
>> alongside each
On 14 Oct 2016, at 15:36, David Scott wrote:
>
> Looks like we have a number of different conventions for the binds. Do we
> want to have the same set of operators with and without Lwt support (and open
> the Infix module locally as needed) or separate operators that be used
> alongside each
> On 14 Oct 2016, at 15:31, Hannes Mehnert wrote:
>
> [again raising the issue: could some mailing list admin please set the
> reply-to to the list -- there's no need to send the message to the
> individual and to the list!]
>
> On 14/10/2016 15:23, Anil Madhavapeddy wrote:
>> On 14 Oct 2016, a
On Fri, Oct 14, 2016 at 3:23 PM, Anil Madhavapeddy wrote:
> On 14 Oct 2016, at 15:11, Hannes Mehnert wrote:
> >
> > On 14/10/2016 15:08, Anil Madhavapeddy wrote:
> >> Yeah, once we agree on the conventions :-) Once we have everything
> using Result.t, we also need to find the right set of combi
On Friday 14 October 2016 at 16:18, Anil Madhavapeddy wrote:
> This is largely within libraries, so the impact wouldn't be too bad. I do
> notice that PCLOCK, MCLOCK and IP types do use option to signify failure
> though, which would be mirage-types churn...
PCLOCK and MCLOCK do not use options
[again raising the issue: could some mailing list admin please set the
reply-to to the list -- there's no need to send the message to the
individual and to the list!]
On 14/10/2016 15:23, Anil Madhavapeddy wrote:
> On 14 Oct 2016, at 15:11, Hannes Mehnert wrote:
>>
>> On 14/10/2016 15:08, Anil Ma
On 10/14/2016 09:08 AM, Richard Mortier wrote:
On 14 October 2016 at 14:51, Anil Madhavapeddy wrote:
Should we take the Mirage3 opportunity to port libraries like Ipaddr to using
the Result type instead
I think that would be a good thing-- only concern would be how much it
would delay the re
On 14 Oct 2016, at 15:11, Hannes Mehnert wrote:
>
> On 14/10/2016 15:08, Anil Madhavapeddy wrote:
>> 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:
>
On 14/10/2016 15:18, Anil Madhavapeddy wrote:
> This is largely within libraries, so the impact wouldn't be too bad. I do
> notice that PCLOCK, MCLOCK and IP types do use option to signify failure
> though, which would be mirage-types churn...
Well, in mirage-types we use (sometimes) `unit Lwt.
On 14/10/2016 15:08, Anil Madhavapeddy wrote:
>
>> On 14 Oct 2016, at 15:05, David Scott wrote:
>>
>>
>> On Fri, Oct 14, 2016 at 2:51 PM, Anil Madhavapeddy wrote:
>>> We have quite a few base libraries that use the pattern of
>>>
>>> val foo_exn : ... -> 'a
>>> @raises
>>>
>>> val foo: ... -> 'a
On 14 Oct 2016, at 15:08, Richard Mortier wrote:
>
> On 14 October 2016 at 14:51, Anil Madhavapeddy wrote:
>> Should we take the Mirage3 opportunity to port libraries like Ipaddr to
>> using the Result type instead
>
> I think that would be a good thing-- only concern would be how much it
> wo
> On 14 Oct 2016, at 15:08, Richard Mortier
> wrote:
>
> On 14 October 2016 at 14:51, Anil Madhavapeddy wrote:
>> Should we take the Mirage3 opportunity to port libraries like Ipaddr to
>> using the Result type instead
>
> I think that would be a good thing-- only concern would be how much i
On 14 October 2016 at 14:51, Anil Madhavapeddy wrote:
> Should we take the Mirage3 opportunity to port libraries like Ipaddr to using
> the Result type instead
I think that would be a good thing-- only concern would be how much it
would delay the release?
(Do we have a timeline for that in fact
> On 14 Oct 2016, at 15:05, David Scott wrote:
>
>
> On Fri, Oct 14, 2016 at 2:51 PM, Anil Madhavapeddy 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
On Fri, Oct 14, 2016 at 2:51 PM, Anil Madhavapeddy 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 lik
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 : ... -
32 matches
Mail list logo
