caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Vincent Hanquez <tab@snarc.org>
Cc: David Allsopp <dra-news@metastack.com>, caml-list@inria.fr
Subject: Re: [Caml-list] Unsoundness is essential
Date: Fri, 05 Oct 2007 01:07:35 +1000	[thread overview]
Message-ID: <1191510455.6518.118.camel@rosella.wigram> (raw)
In-Reply-To: <20071004124549.GA24788@snarc.org>

On Thu, 2007-10-04 at 14:45 +0200, Vincent Hanquez wrote:
> On Thu, Oct 04, 2007 at 12:26:53PM +0100, David Allsopp wrote:
> > Personally, whenever I go back to C, the novelty of the relaxed type
> > system is instantly worn away on the first tricky-to-repeat core dump... at
> > least an Ocaml exception has a cat in hell's chance of being found
> > systematically!
> 
> That's sadly not true. GC bugs in some bindings are usually hard to find !

I think David's point is that many faults in C are diagnosed,
if at all, by a very hard to analyse output (a core dump).
Whereas in Ocaml more bugs are caught at compile time, and,
often a bug at run time has some simple abstract information
such as an exception constructor name, which help in pinpointing
the problem.

I don't think the claim was *elimination* as much as *improvement*.

However I thin David is missing my argument if he's thinking I am
arguing for a more relaxed type system: on the contrary I want an
even tighter type system. The problem is that the cost is likely
to be unsoundness -- in the process of making the type system
more expressive, we're bound to be forced to let some ill-typed
programs through because it is no longer feasible to prove
well-typedness in all cases.

My argument is that this just isn't a problem to worry about:
the only difference is that existing buggy programs which
were previously judged type correct, are no longer decided
as type correct. In some cases a program will be let through
by BOTH type systems, and in others the more expressive 
system will find the error, so the fact that the type system
is unsound is not a problem: our confidence in the correctness
of the program is *enhanced* despite the unsoundness.

Furthermore, my program which today is accepted may be rejected
tomorrow when a theorist finds some way to reduce the unsoundness
by catching more cases. This is impossible if you don't let me
write the annotations just because you can't prove the well
typedness right now!

BTW: when I say 'type system' and 'soundness' I mean
*static type checking*. I do not consider dynamic typing
as a type system in this sense. Any type test at run time
is instant proof of unsoundness of the type system:
an ill typed program has been allowed to escape to run time.

The fact that a policeman is set to catch the inmate who
escaped from jail does not in any way diminish the fact
the inmate indeed escaped, and the jail security system
was unsound (Ouch .. new season of Prison Break .. :)


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  reply	other threads:[~2007-10-04 15:07 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-03  8:35 Locally-polymorphic exceptions [was: folding over a file] oleg
2007-10-03 11:27 ` kirillkh
2007-10-03 11:48   ` [Caml-list] " Daniel de Rauglaudre
2007-10-03 12:19     ` kirillkh
2007-10-03 12:32       ` Daniel de Rauglaudre
2007-10-03 14:34         ` kirillkh
2007-10-03 20:39   ` Christophe Raffalli
2007-10-03 22:50     ` Unsoundness is essential skaller
2007-10-03 23:13       ` [Caml-list] " Jacques Carette
2007-10-04  1:24         ` skaller
2007-10-04 11:26           ` David Allsopp
2007-10-04 12:45             ` Vincent Hanquez
2007-10-04 15:07               ` skaller [this message]
2007-10-03 23:13       ` Vincent Aravantinos
2007-10-04  1:49         ` skaller
2007-10-03 23:28       ` Joshua D. Guttman
2007-10-04  1:52         ` skaller
2007-10-04  2:35           ` Brian Hurt
2007-10-04  7:46           ` Christophe Raffalli
2007-10-04  8:56             ` Arnaud Spiwack
2007-10-04 14:49               ` skaller
2007-10-04 15:00                 ` Harrison, John R
2007-10-04 15:29                 ` Andrej Bauer
2007-10-04 16:25                   ` skaller
2007-10-04 18:17                     ` Arnaud Spiwack
2007-10-04 20:54                       ` skaller
2007-10-04 22:24                         ` Arnaud Spiwack
2007-10-04 16:37                   ` skaller
2007-10-04 18:59                     ` Christophe Raffalli
2007-10-04 15:04               ` Andrej Bauer
2007-10-04 15:57                 ` Christophe Raffalli
2007-10-04 16:03                 ` skaller
2007-10-04 20:02                   ` Ken Rose
2007-10-04 21:00                     ` skaller
2007-10-04 15:31       ` Lukasz Stafiniak
2007-10-04 17:56       ` rossberg
2007-10-04 19:56         ` skaller
2007-10-04 21:07           ` rossberg
2007-10-04 22:23             ` skaller
2007-10-05  2:48               ` Bárður Árantsson
2007-10-04  2:16   ` Locally-polymorphic exceptions [was: folding over a file] oleg

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=1191510455.6518.118.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=dra-news@metastack.com \
    --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).