caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Oliver Bandel <oliver@first.in-berlin.de>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Design-by-contract and Type inference?
Date: Tue, 6 Feb 2007 21:45:07 +0100	[thread overview]
Message-ID: <20070206204507.GV331@first.in-berlin.de> (raw)
In-Reply-To: <wwu4ppzr5w9.fsf@tandem.cs.ru.nl>

Hello,


On Tue, Feb 06, 2007 at 10:29:10AM +0100, Hendrik Tews wrote:
> David MENTRE <dmentre@linux-france.org> writes:
> 
>    Does anybody know if there is research on design-by-contract (as used in
>    Eiffel or Spark) and type inference (as used in OCaml)? For example,
>    relationships between both mechanisms, how the compiler could infer
>    contracts for a sub-class of a class, how contracts can be maintained
>    with minimal work from the programmer (a very useful property of ML type
>    inference), how contract can be statically checked using type inference
>    information, etc.


As far as I know (but I only have seen some simple examples of it),
Design by contract is a way, to make a contract between people
(or for one developer with himself/herself) so that there is an
interface, that will be agreed on.

This is only text with no effect on the code, something like
an interface-description inside comments.

(But maybe it can also be used in different ways, which I don#t know).

As far as I can see, the OCaml's module system (with module-keyword,
or mli-files) offers a contract also, but one, that also has effect
on the program, and is not only comment: editing the signature
in a   "sig ... end" or in an mli-file directly has effect
on what can be seen from the outside of that module.

And that is a contract which necessarily must be accepted.
It's more than only a comment. It's working code.

If you also use abstract types, then it's also not possible
to make awful things inside a module/compilation unit.

> 
> JML for Java is similar to what Eiffel provides. There are a lot
> of tools for JML, for instance ESC/Java for automatics static
> checks.
[...]

You can use the compiler to give you the
signature.

For example

$ ocamlc -i example.ml

Will give you the signature of your file.
But ifyou have narrowed the signature by explicitly
doing it with "sig ... end", then only the explicit
signature will be shown.

Letting the compiler show the signature of your compilation
unit can help a lot in providing *.mli files.

In the above example, it could be done with

$ ocamlc -i example.ml > example.mli

and afterwards you can edit the mli-file.

And the mli-file could be used in a team of developers
in a way that only certain people coulkd edit it, so
that nothing can become broken.
Than the interface is valid and all developers have to use it.

Ciao,
   Oliver


  reply	other threads:[~2007-02-06 20:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-01  5:04 Programming with correctness guarantees oleg
2007-02-01  8:45 ` Andrej Bauer
2007-02-01 13:00   ` [Caml-list] " Chris King
2007-02-01 20:39     ` Jean-Christophe Filliatre
2007-02-01 13:07 ` [Caml-list] " Joshua D. Guttman
2007-02-01 20:12   ` Jean-Christophe Filliatre
2007-02-01 20:35     ` Robert Fischer
2007-02-01 20:57       ` Jean-Christophe Filliatre
2007-02-02  5:47         ` skaller
2007-02-01 20:43     ` Jacques Carette
2007-02-02  0:38       ` Bob Williams
2007-02-02 14:09 ` Jean-Christophe Filliatre
2007-02-03  8:09   ` Tom
2007-02-04 15:47 ` Design-by-contract and Type inference? David MENTRE
2007-02-04 16:04   ` [Caml-list] " Benedikt Grundmann
2007-02-04 16:35   ` Kenn Knowles
2007-02-06  9:29   ` Hendrik Tews
2007-02-06 20:45     ` Oliver Bandel [this message]
2007-02-06 21:35       ` Alwyn Goodloe
2007-02-06 21:50         ` Jacques Carette

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=20070206204507.GV331@first.in-berlin.de \
    --to=oliver@first.in-berlin.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;
as well as URLs for NNTP newsgroup(s).