[OSR] Exceptionless error management, take 2

[OSR] Exceptionless error management, take 2

[David Teller]

   Dear list,

 As it seems that the first take on exceptionless error management has
been discarded, I have put together a second candidate. This proposal
takes into account the discussions from the first candidate, should
resolve the issues introduced by that first candidate -- and presumably
open a few other cans of worms somewhere along the way.

 The draft is available on the cocan wiki [1].

Cheers,
 David

[1]
http://wiki.cocan.org/osr/exceptionless_error_management/recommendation_candidate_2

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Vincent Hanquez]

On Thu, Feb 07, 2008 at 04:01:22PM +0100, David Teller wrote:
>    Dear list,
> 
>  As it seems that the first take on exceptionless error management has
> been discarded, I have put together a second candidate. This proposal
> takes into account the discussions from the first candidate, should
> resolve the issues introduced by that first candidate -- and presumably
> open a few other cans of worms somewhere along the way.
> 
>  The draft is available on the cocan wiki [1].
> 
> Cheers,
>  David

David,

I think the new proposal looks much better than the previous one.

However I was wondering, what do you (and people in general w.r.t. OSR)
expect next if the proposal is accepted ?

Cheers,
-- 
Vincent Hanquez

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Jacques Garrigue]

From: David Teller <David.Teller@univ-orleans.fr>
>  As it seems that the first take on exceptionless error management has
> been discarded, I have put together a second candidate. This proposal
> takes into account the discussions from the first candidate, should
> resolve the issues introduced by that first candidate -- and presumably
> open a few other cans of worms somewhere along the way.
> 
>  The draft is available on the cocan wiki [1].
> 
> Cheers,
>  David
> 
> [1]
> http://wiki.cocan.org/osr/exceptionless_error_management/recommendation_candidate_2

I have little to say about the approach itself (it may certainly be
good to know that there are no hidden exceptions.)

However, the comments at the end look just like copied from Vincent
Hanquez's mail.
For me, points 2 and 3 make no sense at all.
Polymorphic variants allow to check exhaustiveness... as long as you
use exhaustive pattern matching (i.e. no wildcard, exactly like for
normal variants.)
And they _cannot_ pollute any namespace, since they define nothing.
The other points are subjective.

Jacques Garrigue

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Jon Harrop]

On Thursday 07 February 2008 15:17:29 Jacques Garrigue wrote:
> However, the comments at the end look just like copied from Vincent
> Hanquez's mail.
> For me, points 2 and 3 make no sense at all.
> Polymorphic variants allow to check exhaustiveness... as long as you
> use exhaustive pattern matching (i.e. no wildcard, exactly like for
> normal variants.)
> And they _cannot_ pollute any namespace, since they define nothing.
> The other points are subjective.

Yes, that's what I thought. I'd also add that the argument that beginners 
might be put off this approach if it uses advanced features like polymorphic 
variants is moot because beginners won't be using this anyway.

Indeed, I think it would be valuable to enumerate exactly who might be using 
this.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Jon Harrop]

On Thursday 07 February 2008 15:01:22 David Teller wrote:
>  As it seems that the first take on exceptionless error management has
> been discarded, I have put together a second candidate. This proposal
> takes into account the discussions from the first candidate, should
> resolve the issues introduced by that first candidate -- and presumably
> open a few other cans of worms somewhere along the way.

There is also some merit in the hierarchical classification of exceptions, 
e.g. as .NET provides (class hierarchies). For example, you might make 
Invalid_argument a base exception with derived exceptions for each of the 
different functions that raise this exception, in order to carry more precise 
information about what exactly went wrong. OCaml's current approach of 
conveying a string argument is not in the API and feels unhygienic as a 
consequence. Like brushing your teeth whilst on the toilet. We all do it, but 
only because we're in a hurry and not because it is an inherently good idea.

Anyway, this can be achieved using variant and polymorphic variant exception 
arguments in OCaml. However, as Zheng Li pointed out late last year, OCaml is 
broken with respect to polymorphic variant exception arguments, e.g. this 
segfaults:

  exception E of [>];; 
  try raise(E`X) with E`X x-> !x

I don't know where the boundary in the language lies, beyond which it is 
unsafe/wrong, so I think it would be constructive to describe this and 
your "exception+polymorphic variant"-related proposal seems like a good place 
to do so.

Just an idea...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

On Fri, 2008-02-08 at 00:17 +0900, Jacques Garrigue wrote:
> I have little to say about the approach itself (it may certainly be
> good to know that there are no hidden exceptions.)
> 
> However, the comments at the end look just like copied from Vincent
> Hanquez's mail.
> For me, points 2 and 3 make no sense at all.
> Polymorphic variants allow to check exhaustiveness... as long as you
> use exhaustive pattern matching (i.e. no wildcard, exactly like for
> normal variants.)
> And they _cannot_ pollute any namespace, since they define nothing.
> The other points are subjective.
> 
> Jacques Garrigue

Indeed, they are mostly copied from that mail.

You are correct, the remark about pollution was hasty, I've just removed
it. As for allowing to check exhaustiveness, I grant you that I should
have formulated this differently, but the truth remains that in presence
of wildcards, polymorphic variants allows the very same kind of errors
I'm trying to prevent in this candidate.

For instance, let's consider the following extract:

val parse_int : string -> (int, [`Syntax | `Overflow]) may_fail

match result (parse_int "523.5") with
 | Success i              -> (*...*)
 | Error `IncorrectSyntax -> (*...*)
 | _ as e                 -> throw e

This code is perfectly legitimate. It just happens that it's also false,
because we have used the wrong exception name. It's also the kind of
code which I expect will be quite common: deal with one kind of error
and ignore (or re-raise) the others.

So, while polymorphic variants are quite powerful and quite useful, I
also believe they're the wrong tool for the task.

As for points 1 and 4 are subjective, well, they're open for debate.

Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Olivier Andrieu]

On Feb 7, 2008 4:52 PM, David Teller <David.Teller@univ-orleans.fr> wrote:
> For instance, let's consider the following extract:
>
> val parse_int : string -> (int, [`Syntax | `Overflow]) may_fail
>
> match result (parse_int "523.5") with
>  | Success i              -> (*...*)
>  | Error `IncorrectSyntax -> (*...*)
>  | _ as e                 -> throw e
>
> This code is perfectly legitimate.

Err no, it's not, you'll get a type error since the variant is closed
in the signature of parse_int:

This pattern matches values of type (int, [> `IncorrectSyntax ]) may_fail
but is here used to match values of type
  (int, [ `Overflow | `Syntax ]) may_fail
The second variant type does not allow tag(s) `IncorrectSyntax

-- 
  Olivier

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

You're correct: if I do specify manually in the interface that the type
of parse_int is 
 string -> (int, [`Syntax | `Overflow]) may_fail
rather than the inferred
 string -> (int, [> `Syntax | `Overflow) may_fail
I will be safe. I hadn't paid attention to that. I'll rectify my
recommendation.

I still believe that's one pitfall too many but yes, the pitfall is much
smaller than what I had in mind.

Cheers,
 David




On Thu, 2008-02-07 at 17:06 +0100, Olivier Andrieu wrote:
> Err no, it's not, you'll get a type error since the variant is closed
> in the signature of parse_int:
> 
> This pattern matches values of type (int, [> `IncorrectSyntax ])
> may_fail
> but is here used to match values of type
>   (int, [ `Overflow | `Syntax ]) may_fail
> The second variant type does not allow tag(s) `IncorrectSyntax
> 
-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

That's an interesting question. I believe we all agree, starting with
Xavier Leroy, that 'Failure of string' was a quick-and-dirty solution
with which we're stuck but should be brushed under the carpet as soon as
possible. In fact, that's one of the problems this recommendation should
help resolve.

Now, concerning hierarchies. My personal experience with Java's
exception hierarchies (which I assume are similar to .Net's) is that the
only circumstance in which I've taken advantage of subtyping was to
relate every exception to the mother-class Exception:

try
 ...
catch(Exception e) //Deal with all exceptions at once, for instance
                   //by turning them into instances of RuntimeError 
 ...

Does anyone have a different experience on the subject ?

Cheers,
 David


On Thu, 2008-02-07 at 15:33 +0000, Jon Harrop wrote:
> There is also some merit in the hierarchical classification of exceptions, 
> e.g. as .NET provides (class hierarchies). For example, you might make 
> Invalid_argument a base exception with derived exceptions for each of the 
> different functions that raise this exception, in order to carry more precise 
> information about what exactly went wrong. OCaml's current approach of 
> conveying a string argument is not in the API and feels unhygienic as a 
> consequence. Like brushing your teeth whilst on the toilet. We all do it, but 
> only because we're in a hurry and not because it is an inherently good idea.

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

On Thu, 2008-02-07 at 16:09 +0100, Vincent Hanquez wrote:
> David,
> 
> I think the new proposal looks much better than the previous one.
> 
> However I was wondering, what do you (and people in general w.r.t. OSR)
> expect next if the proposal is accepted ?
> 
> Cheers,

Well, we expect a massive crowd to cheer and applause and the world to
be changed for the better :)

More seriously, these recommendations are just that, recommendations.
Unless people do follow them, they're useless.

However, once Sylvain has officially launched the OCamlForge, I'm
planning to launch an "OSR standard library" project consisting on a
layer on top of the INRIA standard library, with all the features of the
INRIA standard library but upgraded to compliance with OSR. I hope
distributions would eventually treat as the official standard library.
And yes, this will probably mean including a reworked version of ExtLib.

For this, of course, we'll need volunteers. I'm personally willing to
work on adapting the standard library to exceptionless error management.
I hope someone else will be willing to work on character ropes and
Unicode management, which I believe are the other most critical issues
at hand, once we have an OSR agreement.

Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

Candidate updated to take into account a number of remarks.

Cheers,
 David

On Thu, 2008-02-07 at 16:01 +0100, David Teller wrote:
> Dear list,
> 
>  As it seems that the first take on exceptionless error management has
> been discarded, I have put together a second candidate. This proposal
> takes into account the discussions from the first candidate, should
> resolve the issues introduced by that first candidate -- and presumably
> open a few other cans of worms somewhere along the way.
> 
>  The draft is available on the cocan wiki [1].
> 
> Cheers,
>  David
> 
> [1]
> http://wiki.cocan.org/osr/exceptionless_error_management/recommendation_candidate_2
> 
-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Vincent Hanquez]

On Fri, Feb 08, 2008 at 12:17:29AM +0900, Jacques Garrigue wrote:
> Polymorphic variants allow to check exhaustiveness... as long as you
> use exhaustive pattern matching (i.e. no wildcard, exactly like for
> normal variants.)

well, and "normal" variants allow to check exhaustiveness too in ALL case.
so what's the point in using polymorphics variant then ?

> And they _cannot_ pollute any namespace, since they define nothing.

did you actually read my previous reply ?
they "pollute" since the polymorphic variant namespace is flat, and
don't interact with module (on purpose obviously)

-- 
Vincent Hanquez

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Vincent Hanquez]

On Thu, Feb 07, 2008 at 03:22:28PM +0000, Jon Harrop wrote:
> Yes, that's what I thought. I'd also add that the argument that beginners 
> might be put off this approach if it uses advanced features like polymorphic 
> variants is moot because beginners won't be using this anyway.
> 
> Indeed, I think it would be valuable to enumerate exactly who might be using 
> this.

what about explaining WHY using polymorphic variant is much better than
using normal variant ?

-- 
Vincent Hanquez

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[rlehy]

Selon Vincent Hanquez <tab@snarc.org>:
> On Fri, Feb 08, 2008 at 12:17:29AM +0900, Jacques Garrigue wrote:
> > And [polymorphic variants] _cannot_ pollute any namespace,
> > since they define nothing.
> they "pollute" since the polymorphic variant namespace is flat, and
> don't interact with module (on purpose obviously)

Could you please expand on this "pollution" and the *practical* problems it
causes? I can see the risk of my own identifiers clashing with those of a
library, and that finding documentation when the namespace is flat is harder.
But none of these seem applicable for polymorphic variants, so I feel like I'm
missing something.

-- 
Ronan

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Vincent Hanquez]

On Fri, Feb 08, 2008 at 11:52:18AM +0100, rlehy@free.fr wrote:
> Could you please expand on this "pollution" and the *practical* problems it
> causes? I can see the risk of my own identifiers clashing with those of a
> library, and that finding documentation when the namespace is flat is harder.
> But none of these seem applicable for polymorphic variants, so I feel like I'm
> missing something.

For example, an `Error returned by module X could be use in a code
expecting an `Error returned by module Y, even though that the `Error
could means something totally different (semanticly).  If I use normal
variant, the compiler will prevent me using the same code to match a
X.Error and a Y.Error.

And don't get me wrong, i'm not saying polymorphic variant should never be use,
it has its limited use (when people knows exactly what they are doing),
but usually i prefer keeping this safety net , and like that the
compiler tells me i can't use a Y.Error like a X.Error.

-- 
Vincent Hanquez

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Bünzli Daniel]

Le 8 févr. 08 à 12:56, Vincent Hanquez a écrit :

> For example, an `Error returned by module X could be use in a code
> expecting an `Error returned by module Y, even though that the `Error
> could means something totally different (semanticly).

Only if they have exactly the same error cases (in which case they are  
very likely to attach the same semantics to it). I think you fail to  
think realisitically, chances are little that this is going to pose  
any problems in practice. Do you redefine the option type in each of  
your modules to be able to say this is an optional integer from module  
X ?

> If I use normal variant, the compiler will prevent me using the same  
> code to match a X.Error and a Y.Error.

Note that with this take 2 proposal -- that I personnaly find too  
invasive and heavy weight  -- you won't get that, you will have to  
match on Error.Error (!) instead of `Error (take 1).

Daniel

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

On Fri, 2008-02-08 at 13:40 +0100, Bünzli Daniel wrote:
> Le 8 févr. 08 à 12:56, Vincent Hanquez a écrit :
> > If I use normal variant, the compiler will prevent me using the same  
> > code to match a X.Error and a Y.Error.
> 
> Note that with this take 2 proposal -- that I personnaly find too  
> invasive and heavy weight  -- you won't get that, you will have to  
> match on Error.Error (!) instead of `Error (take 1).
> 
> Daniel

Well, I do expect people to do a "open Error" at some point in their
code.

You are correct that `Error is shorter than Error.Error. On the other
hand, if you intend to use `Error and `Success as a standard for
exceptionless error management, you will need to standardise the use of
these specific polymorphic variants for this specific meaning and to
either teach people how to write closed polymorphic variants or expect
them to miss errors every so often. All this in a context where one of
the main objectives is to make error-management easier and safer.

Both systems have drawbacks -- not quite surprising. I believe that
writing "open Error" if there's no ambiguity and "Error.Error" if there
is any is a small price to pay. So for the moment, I stand behind take
2.

Cheers,
 David

P.S.: Everyone, please don't let this thread degenerate into a slugfest
"polymorphic variants are way kool" vs. "polymorphic variants are
obscene".

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Eric Cooper]

On Fri, Feb 08, 2008 at 04:39:45PM +0100, David Teller wrote:
> Well, I do expect people to do a "open Error" at some point in their
> code.

A small suggestion: name the module Exceptionless, so that
    open Exceptionless
serves as a more useful bit of documentation at the top of a module,
and so that the occasional Exceptionless.Error doesn't look as bad.
(Or substitute another name, but not something as generic as Error.)

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Jon Harrop]

On Friday 08 February 2008 09:53:33 Vincent Hanquez wrote:
> so what's the point in using polymorphics variant then ?

Brevity:

  | Xml.Error.Succeed x -> f x
  | Xml.Error.Failure y -> g y

vs:

  | `Succeed x -> f x
  | `Failure y -> g y

The alternative is to open the namespace that contains the ordinary variant, 
which pollutes your namespace will all of its identifiers.

> > And they _cannot_ pollute any namespace, since they define nothing.
>
> did you actually read my previous reply ?
> they "pollute" since the polymorphic variant namespace is flat, and
> don't interact with module (on purpose obviously)

As Jacques said, polymorphic variants don't define anything, i.e. don't bind 
identifiers to type constructors. So they can't pollute anything. The "flat 
namespace" you refer to doesn't exist.

This is the same as strings. You would not discourage the use of "foo" in 
programs because it "pollutes the flat namespace of strings" for the same 
reason.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Bünzli Daniel]

Le 8 févr. 08 à 16:39, David Teller a écrit :

> On the other hand, if you intend to use `Error and `Success as a  
> standard for
> exceptionless error management, you will need to standardise the use  
> of
> these specific polymorphic variants for this specific meaning and to
> either teach people how to write closed polymorphic variants or expect
> them to miss errors every so often.

That is precisely what take 1 OSR is for.

At the risk of repeating myself, if Pervasives defines a plain variant  
('a, 'b) may_fail = Success of 'a | Error of 'b, I don't care about  
polymorphic variants. The thing is that for now I don't want to depend  
on hypothetical improvements to the standard library performed outside  
the scope of the base distribution. Take 1 allows this, take 2 doesn't  
allow it.

Daniel

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

Good idea.

Cheers,
 David

On Fri, 2008-02-08 at 12:06 -0500, Eric Cooper wrote:
> On Fri, Feb 08, 2008 at 04:39:45PM +0100, David Teller wrote:
> > Well, I do expect people to do a "open Error" at some point in their
> > code.
> 
> A small suggestion: name the module Exceptionless, so that
>     open Exceptionless
> serves as a more useful bit of documentation at the top of a module,
> and so that the occasional Exceptionless.Error doesn't look as bad.
> (Or substitute another name, but not something as generic as Error.)
> 
-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

On Fri, 2008-02-08 at 20:29 +0100, Bünzli Daniel wrote:
> At the risk of repeating myself, if Pervasives defines a plain variant  
> ('a, 'b) may_fail = Success of 'a | Error of 'b, I don't care about  
> polymorphic variants. The thing is that for now I don't want to depend  
> on hypothetical improvements to the standard library performed outside  
> the scope of the base distribution. Take 1 allows this, take 2 doesn't  
> allow it.

Indeed. As I mentioned in another post, I'm quite interested into
getting these "hypothetical improvements to the standard library
performed outside the scope of the base distribution" to take off.

Two different conceptions of what needs to be fixed. Anyway, it's out of
our hands now.

Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Vincent Hanquez]

On Fri, Feb 08, 2008 at 07:07:58PM +0000, Jon Harrop wrote:
> On Friday 08 February 2008 09:53:33 Vincent Hanquez wrote:
> > so what's the point in using polymorphics variant then ?
> 
> Brevity:
> 
>   | Xml.Error.Succeed x -> f x
>   | Xml.Error.Failure y -> g y
> 
> vs:
> 
>   | `Succeed x -> f x
>   | `Failure y -> g y
> 
> The alternative is to open the namespace that contains the ordinary variant, 
> which pollutes your namespace will all of its identifiers.
 
And, I value code readibility more than brevity. in the former case, i
know instantly that what i'm comparing is an Xml error; the later case,
all i know is we compare that either something fail or succeed.

Your option is fine on 100-lines software. it isn't on >= 10K lines
software. 

If the brevity is the only "goodness" of using polymorphics variant,
that's particularly ill-advised.

Brevity doesn't apply to symbols btw. If it would, you'll name all your
variables "a" "b" "c" "d" "e" ... not with useful names.

(programming in fortran is over at least in CS)

> As Jacques said, polymorphic variants don't define anything, i.e. don't bind 
> identifiers to type constructors. So they can't pollute anything. The "flat 
> namespace" you refer to doesn't exist.

It defines a "type annotation" that is shared across all your files in
one project. this type annotation is in its own flat namespace, i.e.
using "`x" in file a.ml is the same as using "`x" in file b.ml
(providing you use the same type with `x obviously)

> This is the same as strings. You would not discourage the use of "foo" in 
> programs because it "pollutes the flat namespace of strings" for the same 
> reason.

except you don't do type checking with strings.

-- 
Vincent Hanquez

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Vincent Hanquez]

On Fri, Feb 08, 2008 at 01:40:09PM +0100, Bünzli Daniel wrote:
> Only if they have exactly the same error cases (in which case they are very 
> likely to attach the same semantics to it). I think you fail to think 
> realisitically, chances are little that this is going to pose any problems 
> in practice.

with growing use of polymorphic variant everywhere, like lots of people
suggest, i can see the number of "collision" raising quickly. specially
defining for regular usage stuff like `Error `Succeed, very common
stuff.

> Do you redefine the option type in each of your modules to be 
> able to say this is an optional integer from module X ?

no, for the simple reason that the option type is (almost) a built-in
type. it could be abuse yes, but everyone knows it's a shared type. like
integer or string.

the "integer 1" is the same in every module, the "error of integer 1" is
probably different.

for example,
in unix: "Error of 1" would means EPERM
in xml: "Error of 1" would means error line 1.

If you working with normal variant, the compiler knows it can't compare
Unix.Error and Xml.Error even though they have the same type attached
(an integer). with polymorphic variant, there's only "`Error of integer"
in both module, so for the compiler they are the same.

>> If I use normal variant, the compiler will prevent me using the same code 
>> to match a X.Error and a Y.Error.
>
> Note that with this take 2 proposal -- that I personnaly find too invasive 
> and heavy weight  -- you won't get that, you will have to match on 
> Error.Error (!) instead of `Error (take 1).

it all boils down in where the thing is going to end up or how it's
going to be use.

-- 
Vincent Hanquez

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Matthew William Cox]

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]

On Fri, Feb 08, 2008 at 07:07:58PM +0000, Jon Harrop wrote:
> As Jacques said, polymorphic variants don't define anything, i.e. don't bind 
> identifiers to type constructors. So they can't pollute anything. The "flat 
> namespace" you refer to doesn't exist.

They do exist in a flat namespace, just not a namespace that resides in
the compiler's abstractions. They do live in the programmer's *mind*,
and there it is crucial to keep things unpolluted. The compiler will
always (modulo bugs) keep things perfectly straight and not confuse
itself. Humans will. (Programming) languages are designed to convey
machine instructions meaningfully to humans, so befuddling the poor
human is working against what the language is there do.

As has been pointed out, `Error 1 could have totally different semantic
meanings in a module for parsing XML, and a module for POSIX functions.

No namespace has been `polluted' since `Error is still available for me
to use. That's not the pollution I'm concerned about. The pollution I
care about is the semantic overlap that *I* have to deal with.

> This is the same as strings. You would not discourage the use of "foo" in 
> programs because it "pollutes the flat namespace of strings" for the same 
> reason.

Sure, values can't pollute anything, just like using a lot of 5's
doesn't pollute the integer namespace. On the other hand, raising
Failure "foo" in 50 different functions for as many different reasons
would be semantic pollution.

Cheers,
Matthew

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

A couple of quick thoughts about the proposal:

   - I don't understand the motivation behind separating out may_fail and
   status.  In the case where no explicit error is returned, we're happy to
   return an ordinary option.  Why not return a status when we want to return
   an error condition? And I don't understand the argument about wanting to
   delay evaluation until the function result is called.  Why is that good, and
   if it's good, why do we still support functions that return options?  The
   whole thing seems to add verbosity with little gain.
   - I think some attention on nomenclature is in order.  In the
   libraries Jane Street uses, we have something similar to status (called
   "result"), but the type is "Ok of 'a | Error of 'b" rather than "Success of
   'a | Error of 'b", simply for terseness.  Also, having a function called
   "result" which converts a "may_fail" into a "status" seems like one name too
   many.  I would call both the function and the type the same thing (either
   status or result).  Unless, of course, you want to imply something material
   about the operation, in which case calling it "eval" or somesuch would make
   sense.
   - I don't understand why this proposal is only for functional data
   types.  I didn't find the motivation given in the OSR for this convincing.
   I feel like the use of exceptions involves roughly the same tradeoffs when
   you're using imperative and functional code.  If you have long functional
   pipelines, doing exception handling at each stage is a pain, much as it is
   if you do long sequences of imperative operations.  That's why I think the
   goal should not be for the interfaces to be "exceptionless" so much as to
   make it easier to keep track of where exceptions might and might not be
   thrown, so that the reader of a piece of code knows where to stop and worry
   about exceptions.

y

[-- Attachment #2: Type: text/html, Size: 2045 bytes --]

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

On Sun, 2008-02-10 at 13:47 -0500, Yaron Minsky wrote:
> A couple of quick thoughts about the proposal:
>       * I don't understand the motivation behind separating out
>         may_fail and status.  In the case where no explicit error is
>         returned, we're happy to return an ordinary option.  Why not
>         return a status when we want to return an error condition? And
>         I don't understand the argument about wanting to delay
>         evaluation until the function result is called.  Why is that
>         good, and if it's good, why do we still support functions that
>         return options?  The whole thing seems to add verbosity with
>         little gain.

I agree that this is the most arguable part of this recommendation
candidate. I introduced it because 
* it makes possible to decide at a later stage between several
mechanisms for delivering errors from within libraries
* some of these mechanisms make possible to use fully monadic
exceptionless error management, without the usual high cost of fully
monadic exceptionless error management

I have put together three different implementations for such mechanisms
[1] and an example of fully monadic exceptionless error management [2].

[1]
http://www.univ-orleans.fr/lifo/Members/David.Teller/software/exceptionless/exceptionless.ml 
[2]
http://www.univ-orleans.fr/lifo/Members/David.Teller/software/exceptionless/test_monad.ml
      * 
      * 
>       * I think some attention on nomenclature is in order.  In the
>         libraries Jane Street uses, we have something similar to
>         status (called "result"), but the type is "Ok of 'a | Error of
>         'b" rather than "Success of 'a | Error of 'b", simply for
>         terseness.  Also, having a function called "result" which
>         converts a "may_fail" into a "status" seems like one name too
>         many.  I would call both the function and the type the same
>         thing (either status or result).  Unless, of course, you want
>         to imply something material about the operation, in which case
>         calling it "eval" or somesuch would make sense.

Interesting question. You are correct that "eval" might make more sense
and I believe nobody would object to "Ok|Error" instead of "Success|
Error". If terseness is a concern, "Bad" might even make a shorter
replacement for "Error", although this would probably be harder to read.

>       * I don't understand why this proposal is only for functional
>         data types.  I didn't find the motivation given in the OSR for
>         this convincing.  I feel like the use of exceptions involves
>         roughly the same tradeoffs when you're using imperative and
>         functional code.  If you have long functional pipelines, doing
>         exception handling at each stage is a pain, much as it is if
>         you do long sequences of imperative operations.  That's why I
>         think the goal should not be for the interfaces to be
>         "exceptionless" so much as to make it easier to keep track of
>         where exceptions might and might not be thrown, so that the
>         reader of a piece of code knows where to stop and worry about
>         exceptions.

My intuition is that managing errors with ('a, 'b) status (or whatever
this name may become) is mostly functional in the first place. I have in
mind functions such as Unix.rename, which return nothing but may fail.
Without exceptions, one would need to stop at each step to check if no
error has occurred. 

Of course, we can handle this with monadic operators, just as we would
handle errors in functional code. I believe this monadic approach is as
close as we can get to having errors tracked by the type system without
requiring the user to handle them at each step along the road.

Now, I admit that I usually write functional code, so input from people
dealing in imperative code in OCaml would be interesting.

> y

Cheers,
 David
-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 6064 bytes --]

On Feb 10, 2008 5:05 PM, David Teller <David.Teller@univ-orleans.fr> wrote:

> On Sun, 2008-02-10 at 13:47 -0500, Yaron Minsky wrote:
> > A couple of quick thoughts about the proposal:
> >       * I don't understand the motivation behind separating out
> >         may_fail and status.  In the case where no explicit error is
> >         returned, we're happy to return an ordinary option.  Why not
> >         return a status when we want to return an error condition? And
> >         I don't understand the argument about wanting to delay
> >         evaluation until the function result is called.  Why is that
> >         good, and if it's good, why do we still support functions that
> >         return options?  The whole thing seems to add verbosity with
> >         little gain.
>
> I agree that this is the most arguable part of this recommendation
> candidate. I introduced it because
> * it makes possible to decide at a later stage between several
> mechanisms for delivering errors from within libraries
> * some of these mechanisms make possible to use fully monadic
> exceptionless error management, without the usual high cost of fully
> monadic exceptionless error management


Unless I misunderstand (which is quite likely) you can do fully monadic
error handling without this extra level of indirection.  i.e.:

let bind v f = match v with Error _ as x -> x | Ok y -> f y
let return v = Ok v

There you go, a fully-functioning monad.  Or really a family of monads,
since you basically get a distinct monad for each type of value in the error
position.

I really think we should get far enough in thinking this through to get a
workable suggestion the first time, rather than add this extra bit of
pervasive syntactic noise to allow for some possible future change later.


>
> I have put together three different implementations for such mechanisms
> [1] and an example of fully monadic exceptionless error management [2].
>
> [1]
>
> http://www.univ-orleans.fr/lifo/Members/David.Teller/software/exceptionless/exceptionless.ml
> [2]
>
> http://www.univ-orleans.fr/lifo/Members/David.Teller/software/exceptionless/test_monad.ml
>      *
>      *
> >       * I think some attention on nomenclature is in order.  In the
> >         libraries Jane Street uses, we have something similar to
> >         status (called "result"), but the type is "Ok of 'a | Error of
> >         'b" rather than "Success of 'a | Error of 'b", simply for
> >         terseness.  Also, having a function called "result" which
> >         converts a "may_fail" into a "status" seems like one name too
> >         many.  I would call both the function and the type the same
> >         thing (either status or result).  Unless, of course, you want
> >         to imply something material about the operation, in which case
> >         calling it "eval" or somesuch would make sense.
>
> Interesting question. You are correct that "eval" might make more sense
> and I believe nobody would object to "Ok|Error" instead of "Success|
> Error". If terseness is a concern, "Bad" might even make a shorter
> replacement for "Error", although this would probably be harder to read.


I wouldn't mind type ('a,'b) Result = Ok of 'a | Err of 'b.  Bad seems,
well, bad.


> >       * I don't understand why this proposal is only for functional
> >         data types.  I didn't find the motivation given in the OSR for
> >         this convincing.  I feel like the use of exceptions involves
> >         roughly the same tradeoffs when you're using imperative and
> >         functional code.  If you have long functional pipelines, doing
> >         exception handling at each stage is a pain, much as it is if
> >         you do long sequences of imperative operations.  That's why I
> >         think the goal should not be for the interfaces to be
> >         "exceptionless" so much as to make it easier to keep track of
> >         where exceptions might and might not be thrown, so that the
> >         reader of a piece of code knows where to stop and worry about
> >         exceptions.
>
> My intuition is that managing errors with ('a, 'b) status (or whatever
> this name may become) is mostly functional in the first place. I have in
> mind functions such as Unix.rename, which return nothing but may fail.
> Without exceptions, one would need to stop at each step to check if no
> error has occurred.
>
> Of course, we can handle this with monadic operators, just as we would
> handle errors in functional code. I believe this monadic approach is as
> close as we can get to having errors tracked by the type system without
> requiring the user to handle them at each step along the road.
>
> Now, I admit that I usually write functional code, so input from people
> dealing in imperative code in OCaml would be interesting.


I really think the issue is the same for imperative or functional code.
It's easy enough, even in an imperative version, to have a function like
this:

let throw = function Ok x -> x | Error e -> failwith e

At least assuming that the thing inside the error is a string.  It could
also be an exception, which would then only need to be raised.

I do think it would be helpful to have examples of libraries using these
idioms.  For what it's worth, in a few weeks we hope to release a version of
Jane Street's standard library (which we call "core"), which has a bunch of
examples of these kinds of error-handling patterns.  One thing that's nice
about our library is that it has actually been used in anger, and so we're
pretty sure that the approaches we've taken are at least reasonably usable
in practice.

(As a side, note, I do think there is a lot of charm for using polymorphic
variants for error cases.  It's quite lightweight, and makes for very
pleasant and explicit function signatures.)

y


>
> > y
>
> Cheers,
>  David
> --
> David Teller
>  Security of Distributed Systems
>  http://www.univ-orleans.fr/lifo/Members/David.Teller
>  Angry researcher: French Universities need reforms, but the LRU act
> brings liquidations.
>
>

[-- Attachment #2: Type: text/html, Size: 9169 bytes --]

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

On Sun, 2008-02-10 at 21:16 -0500, Yaron Minsky wrote:

> Unless I misunderstand (which is quite likely) you can do fully
> monadic error handling without this extra level of indirection.  i.e.:
> 
> let bind v f = match v with Error _ as x -> x | Ok y -> f y
> let return v = Ok v
> 
> 
> There you go, a fully-functioning monad.  Or really a family of
> monads, since you basically get a distinct monad for each type of
> value in the error position.

Indeed, if you replace "Error _ as x -> x" by "Error e -> Error e", you
get a fully-functioning family of monads, a solution which is quite
acceptable.

On the other hand, that solution is rather slow, as it is essentially
equivalent to checking at every step of the way whether this has been an
error, then unrolling the stack manually. Unless I'm mistaken, this is
the Haskell way, and it's bound to be slow (I haven't actually
checked). 

With the extra indirection in place, we may add a little magic, as
demonstrated in [1] and use actual exceptions to unroll that stack for
us. 

[1]
http://www.univ-orleans.fr/lifo/Members/David.Teller/software/exceptionless/exceptionless.ml
 
The idea here, is that an expression of type ('a, 'b) may_fail is
actually a function which may either produce a result of type 'a or
raise an OCaml exception of type 'b MonadicException. Since polymorphic
exceptions don't exist in OCaml, it's slightly more complicated, but the
idea is there.

Now, since we have actual exceptions, we need to be certain of when they
are evaluated. That's why function result is there.

Note that we could perform a trivial syntactic optimization using Camlp4
to avoid that call to result. Something such as
attempt expr with
  p1 -> e1
| p2 -> e2
| ...
| pn -> en 

being mapped to

match result ( expr ) with
  p1 -> e1
| p2 -> e2
| ...
| pn -> en 

> I really think we should get far enough in thinking this through to
> get a workable suggestion the first time, rather than add this extra
> bit of pervasive syntactic noise to allow for some possible future
> change later.

Good for me.

>         Interesting question. You are correct that "eval" might make
>         more sense
>         and I believe nobody would object to "Ok|Error" instead of
>         "Success|
>         Error". If terseness is a concern, "Bad" might even make a
>         shorter
>         replacement for "Error", although this would probably be
>         harder to read.
> 
> I wouldn't mind type ('a,'b) Result = Ok of 'a | Err of 'b.  Bad
> seems, well, bad.

I personally consider full words more readable, so I'd somewhat object
to "Err".

> I really think the issue is the same for imperative or functional
> code.  It's easy enough, even in an imperative version, to have a
> function like this:
> 
> let throw = function Ok x -> x | Error e -> failwith e
> 
> At least assuming that the thing inside the error is a string.  It
> could also be an exception, which would then only need to be raised.
> 

That's a possibility. However, I believe we mostly agree that dealing
with errors as strings is usually a bad idea. Unfortunately, if the
error is neither a string nor an exception, in the absence of
polymorphic exceptions, your "throw" wouldn't work. Now, there's always
the monadic option, but I'm not completely sure people would like
monadic error-management right in the middle of their imperative code. 

> I do think it would be helpful to have examples of libraries using
> these idioms.  

I concur.

> For what it's worth, in a few weeks we hope to release a version of
> Jane Street's standard library (which we call "core"), which has a
> bunch of examples of these kinds of error-handling patterns.  One
> thing that's nice about our library is that it has actually been used
> in anger, and so we're pretty sure that the approaches we've taken are
> at least reasonably usable in practice.
> 
> (As a side, note, I do think there is a lot of charm for using
> polymorphic variants for error cases.  It's quite lightweight, and
> makes for very pleasant and explicit function signatures.)

On that subject, one day I'm for them, one day I'm against. I believe
that my biggest issue is that the default typing of polymorphic variants
is open:

# `blue ;;
- : [ > `blue ] = `blue

I believe I understand that choice. It's probably needed to be able to
type 

  fun 0 -> `blue | _ -> `red 

Unfortunately, as discussed previously on the mailing-list, open
polymorphic variants are not quite as foolproof as regular variants.

> y

Cheers,
 David

-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act
brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

Something about this whole error-handling proposal confuses me.  Here's my
concern: I can see 3 approaches, all having to do with what goes in the 'b
slot in the ('a,'b) status type:

   1. Use different, wholly incompatible types in 'b.  This allows you to
   put useful information into the signature of each error-producing function,
   but basically requires individual handling of each error.  No monadic magic
   and no conversion to exceptions is possible, and each error must be handled
   individually.  It's more explicit and more verbose.
   2. Use the same type in 'b everywhere.  There's no extra explicitness
   here, and I don't actually see any advantage over just using exceptions.
   3. Use different but compatible types, e.g., polymorphic variants.
   Then you get both explicitness and the chance to use monadic or other tricks
   to join together the errors at the type level.  That has some clear
   advantages (the type system can infer for you the ser of all possible error
   messages), but we've found it leads to some sticky type error messages in
   some cases.

So, I understand why someone would try (1) or (3), but (2) seems utterly
pointless to me.  The proposal seems to be aiming at (1), but then there's
all this talk of monads which doesn't seem to fit (1).

Am I missing something?

y

[-- Attachment #2: Type: text/html, Size: 1417 bytes --]

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[David Teller]

I'm not sure where you see approach 2. 

My suggestion deals with approach 1, while Daniel's is approach 3. The
point of monads is not related to converting exceptions, but rather to
being able to compose functions without having to add a manual check at
each step. And the point of this "optimized" monad implementation is
just to make that faster.

If the confusion is caused by my answer to your previous post, I just
realized that my fixing your "bind" was a mistake. Please accept my
apologies, I misread what you had written.

Now, if this candidate is too confusing -- which I can't judge, as I
wrote it -- perhaps something less confusing would be more appropriate. 

Cheers,
 David

On Mon, 2008-02-11 at 07:12 -0500, Yaron Minsky wrote:
> Something about this whole error-handling proposal confuses me.
> Here's my concern: I can see 3 approaches, all having to do with what
> goes in the 'b slot in the ('a,'b) status type:
>      1. Use different, wholly incompatible types in 'b.  This allows
>         you to put useful information into the signature of each
>         error-producing function, but basically requires individual
>         handling of each error.  No monadic magic and no conversion to
>         exceptions is possible, and each error must be handled
>         individually.  It's more explicit and more verbose.
>      2. Use the same type in 'b everywhere.  There's no extra
>         explicitness here, and I don't actually see any advantage over
>         just using exceptions.
>      3. Use different but compatible types, e.g., polymorphic
>         variants.  Then you get both explicitness and the chance to
>         use monadic or other tricks to join together the errors at the
>         type level.  That has some clear advantages (the type system
>         can infer for you the ser of all possible error messages), but
>         we've found it leads to some sticky type error messages in
>         some cases.
> So, I understand why someone would try (1) or (3), but (2) seems
> utterly pointless to me.  The proposal seems to be aiming at (1), but
> then there's all this talk of monads which doesn't seem to fit (1).
> 
> Am I missing something?
> 
> y
-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 

Re: [Caml-list] [OSR] Exceptionless error management, take 2

[Yaron Minsky]

On Feb 11, 2008, at 7:53 AM, David Teller <David.Teller@univ- 
orleans.fr> wrote:

> I'm not sure where you see approach 2.

I'm probably the one being confusing here. My only point is: the  
monadic interface seems unlikely to work well, and so it seems to me  
like a bad idea to make compromises to the simplicity and terseness of  
the approach for the potential of making an efficient monadic  
implementation later.

In short, I would use the status type directly and eliminate the  
may_fail

Y

> My suggestion deals with approach 1, while Daniel's is approach 3. The
> point of monads is not related to converting exceptions, but rather to
> being able to compose functions without having to add a manual check  
> at
> each step. And the point of this "optimized" monad implementation is
> just to make that faster.
>
> If the confusion is caused by my answer to your previous post, I just
> realized that my fixing your "bind" was a mistake. Please accept my
> apologies, I misread what you had written.
>
> Now, if this candidate is too confusing -- which I can't judge, as I
> wrote it -- perhaps something less confusing would be more  
> appropriate.
>
> Cheers,
> David
>
> On Mon, 2008-02-11 at 07:12 -0500, Yaron Minsky wrote:
>> Something about this whole error-handling proposal confuses me.
>> Here's my concern: I can see 3 approaches, all having to do with what
>> goes in the 'b slot in the ('a,'b) status type:
>>     1. Use different, wholly incompatible types in 'b.  This allows
>>        you to put useful information into the signature of each
>>        error-producing function, but basically requires individual
>>        handling of each error.  No monadic magic and no conversion to
>>        exceptions is possible, and each error must be handled
>>        individually.  It's more explicit and more verbose.
>>     2. Use the same type in 'b everywhere.  There's no extra
>>        explicitness here, and I don't actually see any advantage over
>>        just using exceptions.
>>     3. Use different but compatible types, e.g., polymorphic
>>        variants.  Then you get both explicitness and the chance to
>>        use monadic or other tricks to join together the errors at the
>>        type level.  That has some clear advantages (the type system
>>        can infer for you the ser of all possible error messages), but
>>        we've found it leads to some sticky type error messages in
>>        some cases.
>> So, I understand why someone would try (1) or (3), but (2) seems
>> utterly pointless to me.  The proposal seems to be aiming at (1), but
>> then there's all this talk of monads which doesn't seem to fit (1).
>>
>> Am I missing something?
>>
>> y
> -- 
> David Teller
> Security of Distributed Systems
>  http://www.univ-orleans.fr/lifo/Members/David.Teller
> Angry researcher: French Universities need reforms, but the LRU act  
> brings liquidations.
>