caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Andrej.Bauer@andrej.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Unsoundness is essential
Date: Fri, 05 Oct 2007 02:25:20 +1000	[thread overview]
Message-ID: <1191515120.6518.173.camel@rosella.wigram> (raw)
In-Reply-To: <470506D9.3080704@fmf.uni-lj.si>

On Thu, 2007-10-04 at 17:29 +0200, Andrej Bauer wrote:

> Skaller, you want something like this:
> 
> (a) expressive power (dependent types, subsets, you-name-it)
> 
> (b) soundness, in the following form:
>      * the compiler rejects obvious nonsense
>      * the result of a compilation is a program and a list of
>        assertions which the compiler was unable to verify

Yes, I want something like that.

> This I would call "controlled unsoundness" 

As an (eX) motorcyclist I can agree .. riding a bike is like
having one continuous controlled road accident.. :)

> which at least allows the 
> human to see what needs to be verified to guarantee soundness. It's much 
> better than the sort of unsoundness that skaller seems to be advocating.

Sure, but my point does remain: the expressiveness is more or less
paramount. It is not so much that I personally desire it or not,
but that real programmers in the real world go out there and do
whatever is necessary to make programs work.

If you can produce a compiler with an expressive type system
but cannot yet create a complete list of unproven assertions,
that is still better than writing Python. In fact I write a lot
of Python even now. I do not do so in ignorance of the value
of static type checking! There is a good reason I choose it,
for example for the Felix build system.

It is not because I fear writing all the types Ocaml would
require, but because the need for 'dynamic typing' in this
kind of software and the lack of expressiveness in Ocaml
type system makes Ocaml unsuitable. Please note I'm *trying*
to explain the reason, but probably haven't got it right.

The point is, in the manifesto it should go like: expressiveness
first, then generating proof obligations, and also with time,
improving the automatic provers. 

The key thing is not to restrict expressiveness just because
the type system cannot fully cope.. making the typing more
expressive has many benefits by itself.

A stupid one: how can theoreticians test the efficacy of a new
algorithm with real world case data?


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


  reply	other threads:[~2007-10-04 16:25 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
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 [this message]
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=1191515120.6518.173.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=Andrej.Bauer@andrej.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).