caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Harrison <John.Harrison@cl.cam.ac.uk>
To: caml-list@margaux.inria.fr
Cc: John.Harrison@cl.cam.ac.uk
Subject: Re: Irrelevant variables in patterns
Date: Mon, 30 May 94 15:49:46 +0100	[thread overview]
Message-ID: <"swan.cl.cam.:029090:940530144959"@cl.cam.ac.uk> (raw)
In-Reply-To: Your message of "Sat, 28 May 94 12:43:29 +0200." <29438.770121809@pauillac.inria.fr>


Chet writes:

| Exceptions in ML are a programming mechanism.  They are not used
| anymore for exceptional conditions.  We need a new mechanism for that.

In the HOL theorem prover we use exceptions to indicate that certain
inference rules are inapplicable. It's quite common for code to trap
failures at certain subterms and conclude "we have rewritten this subterm
as much as possible, so return it". In the present code (including hol90 in
SML) most of the exceptions are caught completely indiscriminately, i.e.
`_' not `HOL_ERR(_)'. This means there are situations where exceptional
conditions just get driven over. Really the code should be rewritten, but
as Chet remarks, there's something to be said for a separate signal
mechanism.

| Moreover, even if I _do_ write the code in handle_exceptions_generally
| to treat Out_of_memory, etc, I get many warnings telling me that I am
| catching the exception.

Which raises another point. Is there a way to suppress the incredibly
irritating (and I seem to recall not very accurate) "match not exhaustive"
messages in CAML Light (in general expression matching as well as
exceptions)? I find myself putting in redundant clauses to avoid them,
which is hardly good style. It's especially pointless when the match is
actually done at toplevel, e.g.

  let [x;y] = [1;2];;

As Christophe says:

|                               [...] Then what you really needs is a compiler
| option to discard a particular warning (or class or warning) so you only get
| the warnings which are relevant to you programming style.

I agree completely.

John.




  parent reply	other threads:[~1994-05-30 16:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-05-26 13:03 Judicael Courant
1994-05-27 18:01 ` Christophe Raffalli
1994-05-28 10:16   ` Chet Murthy
1994-05-28 10:36     ` Christophe Raffalli
1994-05-28 10:43       ` Chet Murthy
1994-05-28 11:01         ` Christophe Raffalli
1994-05-28 11:05           ` Chet Murthy
1994-05-28 11:09             ` Christophe Raffalli
1994-05-28 11:08         ` Christophe Raffalli
1994-05-28 11:12           ` Chet Murthy
1994-05-30 14:49         ` John Harrison [this message]
1994-05-30 18:20           ` calla
1994-05-30  8:53 ` Xavier Leroy
1994-05-30 17:57   ` Christophe Raffalli
1994-05-27 18:58 Damien Doligez
1994-05-30 13:15 Judicael Courant

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='"swan.cl.cam.:029090:940530144959"@cl.cam.ac.uk' \
    --to=john.harrison@cl.cam.ac.uk \
    --cc=caml-list@margaux.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).