From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 98F8FBC69 for ; Fri, 16 Nov 2007 20:18:32 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACF7PUfC2fJcnmdsb2JhbACPDQEBAQEHBAYpgQ8 X-IronPort-AV: E=Sophos;i="4.21,428,1188770400"; d="scan'208";a="4585203" Received: from anchor-post-34.mail.demon.net ([194.217.242.92]) by mail1-smtp-roc.national.inria.fr with ESMTP; 16 Nov 2007 20:18:32 +0100 Received: from orion.metastack.com ([80.177.38.218]) by anchor-post-34.mail.demon.net with esmtp (Exim 4.67) id 1It6hz-0004o0-Dv for caml-list@yquem.inria.fr; Fri, 16 Nov 2007 19:18:31 +0000 Received: from countertenor (cpc3-cmbg6-0-0-cust100.cmbg.cable.ntl.com [81.101.140.101]) (authenticated bits=0) by orion.metastack.com (8.13.4/8.13.3) with ESMTP id lAGJDhhN020724 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 16 Nov 2007 19:13:43 GMT From: "David Allsopp" To: "'caml-list'" References: <473BE750.9060301@frisch.fr><20071115132649.GB15754@yquem.inria.fr><891bd3390711151630x238b8eddod5b7462d0fa1c735@mail.gmail.com><473D61A3.9090708@frisch.fr><473DD301.90307@gmail.com><473DD956.7090608@gmail.com> <20071116181024.GA15777@gato.physics.und.nodak.edu> Subject: RE: [Caml-list] Compiler feature - useful or not? Date: Fri, 16 Nov 2007 19:18:18 -0000 Organization: MetaStack Solutions Ltd. Message-ID: <00a701c82885$726915b0$017ca8c0@countertenor> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acgoe2WOBriF1KwFSMSSdz/pQM7jEwAB0f4A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20071116181024.GA15777@gato.physics.und.nodak.edu> X-Scanned-By: MIMEDefang 2.63 on 172.16.28.218 X-Spam: no; 0.00; compiler:01 runtime:01 run-time:01 ocaml:01 type-safe:01 typecheck:01 segfault:01 runtime:01 o'caml:01 compiler:01 sml:01 constants:01 equality:01 wrote:01 exception:01 Fernando Alegre wrote: > > permission and back. And automatically generated runtime checks to > > ensure that you don't try to convert ( 37 :> permission ). 1 remains an > > No, no. Run-time checks are evil :-) I mean, OCaml is supposed to be > a static type-safe system, so that programs that typecheck are guaranteed > to run (maybe forever...) and never segfault. This isn't a runtime type-check - it's a runtime domain check and it's necessary in the absence of a much more exotic type system that includes information on the domain and range of a function as well as it's "raw" type. Getting an int from a permission is an error-free process (because all permissions are ints) but getting a permission from an int can fail because only some ints are permissions. You need to have a runtime check (or a proof - which isn't how O'Caml works) that the int is valid. Spotting and eliminating conversion of constants would of course be a good compiler optimisation but permission_of_int (or whatever conversion construct you came up with) would need to raise an exception on invalid input. 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). David