caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Radu Grigore <radugrigore@gmail.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] assertions or exceptions?
Date: Thu, 15 Jul 2004 16:45:34 +0300	[thread overview]
Message-ID: <7f8e92aa04071506453ef7345d@mail.gmail.com> (raw)
In-Reply-To: <200407151335.23097.postmaster@jdh30.plus.com>

On Thu, 15 Jul 2004 13:35:22 +0100, Jon Harrop
<postmaster@jdh30.plus.com> wrote:

> [...] In
> OCaml, you often write in a functional style, when performing many similar
> operations this naturally lends itself to recursive functions. When running,
> a deeply recursed function may suddenly find a shortcut to the correct
> answer. Exceptions provide an ideal means to escape such deep recursions. 

This is an interesting idea. I'll try to spot such situations while coding!

> Convert the following code (which finds the product of a bunch of integers)
> into an equivalent which avoids exceptions but retains the efficiency of
> being able to bail earlier, upon encountering a zero:
> 
> exception Zero
> 
> let prod fold l =
>   try fold (fun a e -> if e=0 then raise Zero else a*e) 1 l
>   with Zero -> 0;;

All I can do is this:

let rec prod_fold a l = match a, l with
  | 0, _ -> 0
  | a, [] -> a
  | a, h :: t -> prod_fold (a * h) t

Differences between these are:
1. Yours makes an exception visible to other functions that do not use it
2. Yours is 80 non-ws characters long, mine is 71 characters long; so
they are comparable.
3. Mine is less flexible: it does not allow plugging in a fold
function. However I don't see where such a thing would be useful. An
example?
4. I assert that mine is easier to understand. (at least for me :) )
One reason is that it doesn't use exceptions: only a simple recursive
function.
5. I see no reason why performance would be significantly different.

> > Exceptions can be left uncaught and this is a potential cause
> > for a combinatorial explosion of the number of possible "execution
> > paths"...
> 
> I would say it was poor style to allow the possible number of execution paths
> to explode.

You can use goto and keep the number of execution paths from exploding
too. This doesn't mean that it is not a dangerous tool and that you
should be careful while using it. The same applies to exceptions.

> As the above example shows, exceptions can be used to simplify code.

I'm not convinced.

> > 3. Is it possible to avoid using exceptions and read a text file
> > line-by-line until EOF?
> 
> Yes (see other people's posts).

Those solutions are:
 1. use another library
 2. provide your own workaround (by redesigning the interface)
I fail to see how this vindicates the design of the standard library.

> > 4. When do you use assertions and when do you use exceptions?
> 
> I use assertions to perform sanity checks.

You mean internal invariants? That is, including postconditions but
not preconditions?

> I use exceptions in two separate
> sitations: firstly to handle exceptional circumstances,

Tautologies do not contain a lot of information ;-) When is something
exceptional? When it shouldn't happen but you know what to do if it
does happen? If you remove the "but you know what to do.." part then
you are better of using an assertion.

> secondly to provide an escape route from computations.

As I said, this is an interesting idea but I really need to see it in
practice in order to understand it.

regards, 
 radu

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2004-07-15 13:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-15  8:03 Radu Grigore
2004-07-15 10:18 ` Richard Jones
2004-07-15 10:28   ` Daniel Andor
2004-07-15 12:49   ` Radu Grigore
2004-07-15 13:33     ` Richard Jones
2004-07-15 13:58       ` Radu Grigore
2004-07-16 18:53         ` Aleksey Nogin
2004-07-17  2:55           ` John Prevost
2004-07-17 14:24             ` David MENTRE
2004-07-15 12:35 ` Jon Harrop
2004-07-15 13:45   ` Radu Grigore [this message]
2004-07-15 14:33     ` Jon Harrop
2004-07-15 15:05       ` Radu Grigore
2004-07-15 16:24     ` skaller
2004-07-15 15:38 ` [Caml-list] Unboxing options, was " Brian Hurt
2004-07-15 16:25   ` John Hughes
2004-07-15 17:00     ` Brian Hurt
2004-07-15 17:20   ` John Prevost
2004-07-15 19:14     ` Radu Grigore
2004-07-15 19:56     ` John Carr
2004-07-15 20:48       ` Brian Hurt
2004-07-15 20:49         ` John Carr
2004-07-15 21:15           ` John Prevost
2004-07-15 21:15           ` Karl Zilles
2004-07-15 21:26           ` Brian Hurt
2004-07-15 21:04       ` John Prevost
2004-07-15 21:17     ` skaller
2004-07-15 21:35       ` Brian Hurt
2004-07-15 21:51         ` skaller
2004-07-15 21:42       ` skaller
2004-07-16  0:35     ` Jacques GARRIGUE
2004-07-16  1:03       ` John Prevost
2004-07-16  2:00         ` Jacques GARRIGUE
2004-07-16 16:40         ` Xavier Leroy
2004-07-19  8:58           ` Damien Doligez

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=7f8e92aa04071506453ef7345d@mail.gmail.com \
    --to=radugrigore@gmail.com \
    --cc=caml-list@inria.fr \
    /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).