Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Hendrik Tews <tews@tcs.inf.tu-dresden.de>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Formal Methods
Date: 01 Oct 2004 10:30:13 +0200	[thread overview]
Message-ID: <rlzn36zvqi.fsf@ithif59.inf.tu-dresden.de> (raw)
In-Reply-To: <959E4FC0-12F8-11D9-A9B7-000A95C19BAA@Avisere.com>

David McClain <David.McClain@Avisere.com> writes:

   I have just been reviewing some papers by Greg Chaitin on Algorithmic
   Complexity Theory, in which he boldly states that
   
   "Similarly, proving correctness of software using formal methods is
   hopeless. 

This is just nonsense. You can prove the correctness of any piece
of software (provided it is correct). Its only some orders of
magnitute more expensive than developing the same software,
therefore proving correctness is seldom attempted in practice. 

Further the halting problem is just not relevant here. It only
means that you can not hope for a fully automatic procedure.
However, every decent programmer knows why his while loops
terminate. So you just go and ask him and use his answer in your
correctness proof. In general, software verification is not
difficult, it is complex. 

   I wonder, as a non-specialist in this area, how the goals of FPL
   squares with this result?
   
If you have a well-typed programm for a language with a strong
type system you can use a simpler semantics. Thus verification
becomes cheaper. Now, if you have a side-effect free language,
like Haskell, it becomes even more simpler and cheaper. However,
nowadays a semantics exists even for quite dirty languages like
Java, C or C++. You are not bound to functional programming if
you want to use formal methods. Goto statements, pointer
arithmetic and even type casts are not a problem if you use the
right technology.

Bye,

Hendrik Tews 

(I am working in the VFiasco project that attempts to verify
properties of the Fiasco micro-kernel written in C++. 
Checkout http://os.inf.tu-dresden.de/vfiasco/) 

-------------------
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


  parent reply	other threads:[~2004-10-01  8:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-30 15:51 David McClain
2004-09-30 17:35 ` Jacques Carette
2004-09-30 18:42   ` Jon Harrop
2004-10-01  8:24   ` Thomas Fischbacher
2004-10-01  9:01     ` Achim Blumensath
2004-09-30 17:54 ` [Off-topic] " David MENTRE
2004-10-01  7:36 ` Jean-Christophe Filliatre
2004-10-01  7:51   ` Tom
2004-10-01  9:04   ` Martin Berger
2004-10-01  8:30 ` Hendrik Tews [this message]
2004-10-01  9:18   ` Martin Berger
2004-09-30 17:19 Harrison, John R

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=rlzn36zvqi.fsf@ithif59.inf.tu-dresden.de \
    --to=tews@tcs.inf.tu-dresden.de \
    --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