caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Teller <David.Teller@univ-orleans.fr>
To: Vincent Hanquez <tab@snarc.org>
Cc: "Bünzli Daniel" <daniel.buenzli@erratique.ch>,
	"caml-list List" <caml-list@inria.fr>
Subject: Re: [Caml-list] [OSR] Exceptionless error management
Date: Tue, 05 Feb 2008 15:12:49 +0100	[thread overview]
Message-ID: <1202220770.6226.77.camel@Blefuscu> (raw)
In-Reply-To: <20080205101221.GA3922@snarc.org>

On Tue, 2008-02-05 at 11:12 +0100, Vincent Hanquez wrote:
> On Tue, Feb 05, 2008 at 11:00:44AM +0100, David Teller wrote:
> >  The debate on this subject seems to have calmed down. A tentative set
> > of recommendations have been put together on the wiki [1] by some of the
> > participants. It looks coherent and well-written. If nothing springs
> > back to the front of the scene within a few days, I'll post this again
> > to the mailing-list as a call for votes.
> 
> looking at the page, I find a proposal (beginning), and a lots of people
> disaggreeing at the end.
> 
> I can see lots of people are concerned by using polymorphic variant (and
> I certainly agree with those), and people asking for a monadic approch
> (haskell's either like). I can see anything change in the proposal
> regarding people's concerned, so what are you going to call for a vote ?

Ok, my bad, I guess I misunderstood silence for consensus.

In this case, let me try and sum up the discussion. I'll use the term
"exception" for OCaml's built-in exception system.

1) This recommendation applies to functional libraries, by opposition to
essentially imperative libraries such as Unix.
[ I believe everybody agrees with that ]

2) This recommendation only applies to the interface of libraries,
rather than their non-observable implementation or their use by clients.
[ I believe everybody agrees with that ]

3) Exceptions passing library barriers should be reserved for programmer
errors (i.e. invalid arguments and impossible-to-reach states) rather
than previsible errors (e.g. sometimes, a key does not map to a value).
We already have standard names for such exceptions.
[ I have the impression nobody disagrees with that, either ]

4) At hand, to provide non-exception error management, we have the
following tools:
* 'a option 
* something such as ('a, 'b) either  -- exact name and constructors
remain to be decided, but the general idea is there -- which may serve,
if necessary, as the base for error monads
* polymorphic variants
* an implementation of error monad based on exceptions, which may be
trivially degraded to   ('a, 'b) either   whenever necessary.

(I'm discounting my own suggestion for functor-based error reporting as
I haven't had time to work on that, plus it would actually solve a
different problem)

[ Unless I'm mistaken, these are the only tools suggested so far ]

5) We may need to differentiate functions which raise exceptions.
Someone on this thread suggested adding suffix "_exn" to the name of
such functions. Another possibility would be to define a type such as
  type 'a raising = 'a
to document the fact that a function may raise an exception.

[ No discussion on this yet ]


6) Assuming that no other tools come into the discussion, we need to
determine which tools are best for which situation.

There seems to be an agreement that polymorphic variant are too fragile
for general use. This leaves us essentially 
* ('a,'b) either  (of which 'a option is just a special case)
* the exception-based error monad, with the ability to produce results
of type 'a or errors of type 'b . 

These cases are fundamentally equivalent, each may be used to build the
other and result in essentially the same type signature.

[ No discussion on this yet ]


7) Assuming that we use one of these two possibilities, we need to
decide what to put in the 'b. 

Here, we may decide to:
* either define module-specific types ; 
* or use polymorphic variants.

Again, the general consensus seems to be that polymorphic variants are
too risky. On the other hand, we may also decide not to specify at all
what to put in 'b and to let each developer decide for their own
library.

[ No discussion on this yet ]




As a test, I've adapted the interface of the List module.
* I've included the interface for both possibilities
* I've postfixing exception-raising functions with "_exn"
* I've defined module-specific sum types, some of which could presumably
be moved to Pervasives.

You may find the result here:
http://www.univ-orleans.fr/lifo/Members/David.Teller/software/exceptions/list_with_errors.mli 

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. 


  parent reply	other threads:[~2008-02-05 14:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-31  8:55 Bünzli Daniel
2008-01-31  9:57 ` [Caml-list] " Till Varoquaux
2008-01-31 11:01   ` Bünzli Daniel
2008-01-31 14:09     ` Andrej Bauer
2008-01-31 14:16       ` Michael Ekstrand
2008-01-31 19:28         ` David Teller
2008-01-31 19:59           ` Michael Ekstrand
2008-01-31 20:05           ` blue storm
2008-01-31 20:03       ` Bünzli Daniel
2008-01-31 20:25         ` David Teller
2008-01-31 20:40           ` David Teller
2008-01-31 21:16           ` Bünzli Daniel
2008-01-31 21:31             ` David Teller
2008-01-31 21:35           ` Jon Harrop
2008-01-31 22:01           ` Christophe Raffalli
2008-02-01  7:27         ` Michaël Grünewald
2008-02-01  7:47           ` Bünzli Daniel
2008-02-01 10:50             ` Till Varoquaux
2008-02-01 11:31               ` Bünzli Daniel
2008-02-01 15:59                 ` Vincent Hanquez
2008-02-01 18:37                   ` Bünzli Daniel
2008-02-01 19:43                     ` Vincent Hanquez
2008-02-01 16:04                 ` David Allsopp
2008-02-01  8:31 ` David Teller
2008-02-01 12:19   ` Yaron Minsky
2008-02-05 10:00 ` David Teller
2008-02-05 10:12   ` Vincent Hanquez
2008-02-05 10:26     ` Bünzli Daniel
2008-02-05 11:06       ` Vincent Hanquez
2008-02-05 13:46         ` Jon Harrop
2008-02-05 11:36       ` Frédéric van der Plancke
2008-02-06  8:45       ` Michaël Grünewald
2008-02-08 13:09         ` Bünzli Daniel
2008-02-05 14:12     ` David Teller [this message]
2008-02-11  8:12 ` David Teller
2008-02-11  9:09   ` Bünzli Daniel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1202220770.6226.77.camel@Blefuscu \
    --to=david.teller@univ-orleans.fr \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    --cc=tab@snarc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).