From: Thomas Blanc <thomas.blanc@crans.org>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Uncaught exceptions in function type.
Date: Mon, 26 May 2014 17:33:07 +0200 [thread overview]
Message-ID: <53835EB3.5050503@crans.org> (raw)
In-Reply-To: <CAOOOohTKWk6gsz2MFqMniK0MLenRmdvsh8hG1hjqO2cXQJxj0Q@mail.gmail.com>
Le 26/05/2014 16:23, Philippe Veber a écrit :
> Hi everyone,
>
> Out of curiosity, I was wondering how difficult it would be in theory
> to extend the type system so that exceptions that can pop out of a
> function when it is called would be included in the type of the
> function. Could this type information be infered automatically? Could
> this be used to have an exhaustivity check in the "with" part of a try
> ... with expression?
>
> I guess that if it was so easy, we would already be enjoying it within
> our favorite compiler, but I fail to see how hairy is the question.
>
> Cheers,
> Philippe.
>
>
This as already been analyzed by François Pessaux and Xavier Leroy, see
[1] that does a very good survey on the matter.
The main problem for it is (as Romain pointed out) the problem of
higher-order functions:
you would have to reannotate all of your .mli to add the exception
annotations.
([1] solved it by doing a separate type analysis)
This would lead to a lot of problems (along with breaking existing code):
* "exceptions we know won't be throwed":
Typing analysis can't know that "x/2" or a.((Array.length a) - 1)
wouldn't raise anything, so you'd have a lot of unexpected
exceptions that would come up.
* An arbitrary big number of exceptions
At the time [1] was wrote, there was necessarily a finite number of
exceptions in your program, with nifty stuff like first class modules
and generative functors it is no longer the case.
[1] http://pauillac.inria.fr/~xleroy/publi/exceptions-popl.ps.gz
next prev parent reply other threads:[~2014-05-26 15:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-26 14:23 Philippe Veber
2014-05-26 14:56 ` Romain Bardou
2014-05-26 15:13 ` Ben Millwood
2014-05-26 16:02 ` Philippe Veber
2014-05-26 16:34 ` Daniel Bünzli
2014-05-27 6:52 ` Philippe Veber
2014-05-27 8:42 ` Ben Millwood
2014-05-27 10:05 ` Goswin von Brederlow
2014-05-27 10:36 ` Ben Millwood
2014-05-27 11:24 ` Yaron Minsky
2014-05-27 21:42 ` Daniel Bünzli
2014-05-27 21:16 ` Daniel Bünzli
2014-06-02 8:38 ` Goswin von Brederlow
2014-05-27 8:49 ` Goswin von Brederlow
2014-05-27 8:56 ` David House
2014-05-27 21:39 ` Daniel Bünzli
2014-06-02 8:31 ` Goswin von Brederlow
2014-05-27 9:25 ` Nicolas Boulay
2014-05-27 21:51 ` Daniel Bünzli
2014-05-30 18:03 ` Florian Weimer
2014-05-31 11:26 ` Daniel Bünzli
2014-06-02 8:43 ` Goswin von Brederlow
2014-05-26 15:25 ` Philippe Veber
2014-05-27 9:28 ` Goswin von Brederlow
2014-05-27 9:38 ` Romain Bardou
2014-05-26 15:33 ` Thomas Blanc [this message]
2014-05-26 16:04 ` Philippe Veber
2014-05-26 15:33 ` Gabriel Scherer
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=53835EB3.5050503@crans.org \
--to=thomas.blanc@crans.org \
--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