Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Fernando Alegre <fernando@gatech.edu>
To: David Allsopp <dra-news@metastack.com>
Cc: 'caml-list' <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Compiler feature - useful or not?
Date: Fri, 16 Nov 2007 13:32:19 -0600	[thread overview]
Message-ID: <20071116193219.GB22392@gato.physics.und.nodak.edu> (raw)
In-Reply-To: <00a701c82885$726915b0$017ca8c0@countertenor>

On Fri, Nov 16, 2007 at 07:18:18PM -0000, David Allsopp wrote:

> optimisation but permission_of_int (or whatever conversion construct you
> came up with) would need to raise an exception on invalid input.

And that is why "permission_of_int" would not be considered part of
the core language.

However, things like what I proposed earlier, such as

(x :> n finite), whenever x and n are known at compile-time

or

(int :> even), if the encoding of an even number 2*n is given by n

will never raise an exception, are sound and could be part of the core
language. The first case is straightforward, but extending it safely
(i.e. no code, only type equations) is not obvious. The second case
needs some way to specify the encoding along with a proof that it is
sound, and this is not trivial either. However, both extensions seem
theoretically possible and in line with the philosophy of the Caml type
system.

> Consider string_of_int (error-free - all ints can be represented as strings)
> vs. int_of_string which raises an exception if the string is not a
> recognised representation of an int.
> 
> > While exceptions are needed for I/O, no core expression should raise an
> > exception.
> 
> compare = compare;;
> 
> (though cf. SML equality types)
> 
> Good code using permission_of_int (as with good code using int_of_string)
> would ensure that the int is valid before ever calling permission_of_int but
> the permission_of_int itself needs to be able to raise the exception to
> fulfil the contract of its type (int -> permission).

Exactly. And that is the reason why, IMHO, we may never see such an
extension to OCaml language, since it is primarily a research language
for type checking. (And so run-time "usefulness", or hacks, are
secondary to the OCaml team.)

Thanks,
Fernando


  reply	other threads:[~2007-11-16 19:32 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-13 23:41 Edgar Friendly
2007-11-14  0:08 ` [Caml-list] " Yaron Minsky
2007-11-14  0:21   ` Martin Jambon
2007-11-14  7:58     ` Pierre Weis
2007-11-14 12:37       ` Alain Frisch
2007-11-14 13:56         ` Virgile Prevosto
2007-11-14 14:35         ` Pierre Weis
2007-11-14 16:38           ` Alain Frisch
2007-11-14 18:43             ` Pierre Weis
2007-11-14 19:19               ` Edgar Friendly
2007-11-15  6:29               ` Alain Frisch
2007-11-15 13:26                 ` Pierre Weis
2007-11-15 17:29                   ` Edgar Friendly
2007-11-15 20:28                     ` Fernando Alegre
2007-11-16  0:47                       ` Brian Hurt
2007-11-15 22:37                     ` Michaël Le Barbier
2007-11-15 22:24                   ` Michaël Le Barbier
2007-11-16  0:30                   ` Yaron Minsky
2007-11-16  1:51                     ` Martin Jambon
2007-11-16  9:23                       ` Alain Frisch
2007-11-16 14:17                         ` rossberg
2007-11-16 15:08                         ` Martin Jambon
2007-11-16 16:43                           ` Martin Jambon
2007-11-16 16:46                             ` Till Varoquaux
2007-11-16 17:27                             ` Edgar Friendly
2007-11-16 17:47                               ` Martin Jambon
2007-11-16 17:54                                 ` Edgar Friendly
2007-11-16 18:10                                   ` Fernando Alegre
2007-11-16 19:18                                     ` David Allsopp
2007-11-16 19:32                                       ` Fernando Alegre [this message]
2007-11-16 19:50                                         ` Gerd Stolpmann
2007-11-16 17:31                             ` Fernando Alegre
2007-11-16 17:43                               ` Edgar Friendly
2007-11-16  0:46                   ` Christophe TROESTLER
2007-11-16  8:23                     ` Andrej Bauer
2007-11-16  8:58                       ` Jean-Christophe Filliâtre
2007-11-16  9:13                         ` Andrej Bauer
2007-11-16  9:48                           ` Christophe TROESTLER
2007-11-14 16:57       ` Edgar Friendly
2007-11-14 21:04         ` Pierre Weis
2007-11-14 22:09           ` Edgar Friendly
2007-11-15  0:17         ` Jacques Garrigue
2007-11-15  6:23           ` Edgar Friendly
2007-11-15 10:53             ` Vincent Hanquez
2007-11-15 13:48               ` Jacques Carette
2007-11-15 14:43                 ` Jon Harrop
2007-11-15 16:54                   ` Martin Jambon
2007-11-14 16:09   ` Edgar Friendly
2007-11-14 16:20     ` Brian Hurt
2007-11-14 11:01 ` Gerd Stolpmann
2007-11-14 10:57   ` Jon Harrop
2007-11-14 14:37 ` Zheng Li

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=20071116193219.GB22392@gato.physics.und.nodak.edu \
    --to=fernando@gatech.edu \
    --cc=caml-list@yquem.inria.fr \
    --cc=dra-news@metastack.com \
    /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