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=1.0 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 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 911EFBC69 for ; Wed, 14 Nov 2007 14:56:07 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACONOkeBaB4ijGdsb2JhbACPAAEIBAYJBhqBDw X-IronPort-AV: E=Sophos;i="4.21,416,1188770400"; d="scan'208";a="4445971" Received: from mx1.polytechnique.org ([129.104.30.34]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 14:56:07 +0100 Received: from localhost (is005115.intra.cea.fr [132.166.135.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id A0A173316C for ; Wed, 14 Nov 2007 14:56:06 +0100 (CET) Date: Wed, 14 Nov 2007 14:56:05 +0100 From: Virgile Prevosto To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Compiler feature - useful or not? Message-ID: <20071114145605.345f369a@localhost> In-Reply-To: <473AEC04.3030303@frisch.fr> References: <473A363F.2080301@gmail.com> <891bd3390711131608g48b584a4n6b0ccab95d7de3f3@mail.gmail.com> <20071114075827.GA24058@yquem.inria.fr> <473AEC04.3030303@frisch.fr> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.12.0; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-AV-Checked: ClamAV using ClamSMTP at djali.polytechnique.org (Wed Nov 14 14:56:06 2007 +0100 (CET)) X-Org-Mail: virgile.prevosto.1996@polytechnique.org X-Spam: no; 0.00; compiler:01 frisch:01 frisch:01 weis:01 abbreviation:01 subtraction:01 sig:01 val:01 val:01 struct:01 tutto:98 oggi:98 volta:98 equality:01 wrote:01 Le mer 14 nov 2007 13:37:24 CET, Alain Frisch a =C3=A9crit : > Pierre Weis wrote: > > type row =3D private int;; >=20 > The only difference with an abstract type is that some generic=20 > operations (comparision, equality) can be optimized, and currently, > it happens only for some basic types. So exporting a private > abbreviation (instead of an abstract type) is useless when the type > is not a basic type. Is it correct? >=20 As far as I understand Pierre's original email, this is not simply about optimization (which is in fact a simple by-product of the feature). The main point of private is to distinguish between the construction of a value (where you might want to enforce some invariant) and its use (where you might rely on the invariant). You can use a value of type row everywhere a plain int is expected (in particular for addition, subtraction, etc.), without having to redefine the corresponding functions as would have been necessary with an abstract type. On the other hand, the construction of a value of type row from a plain int is impossible outside of the constructor function provided in the module, which checks that the invariant required for row is satisfied. This can be useful for other types as well, consider for instance the following module (not tested of course) module Sorted: sig type sorted_list =3D private int list val empty: sorted_list val insert: int -> sorted_list -> sorted_list end =3D=20 struct type sorted_list =3D int list let empty =3D [] let rec insert x =3D function=20 [] -> [x]=20 | y::_ as l when x < y -> x::l | y::l -> y :: insert x l end A value of type Sorted.sorted_list is a list, for which all operations of module List are available (as well as pattern-matching), but in addition it is guaranteed that a sorted_list is sorted, since it must be built with empty and insert. --=20 E tutto per oggi, a la prossima volta. Virgile