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.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 0A9F5BC69 for ; Fri, 16 Nov 2007 02:51:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMyGPEdCbwQZnmdsb2JhbACPBgIBAQcEBhEY X-IronPort-AV: E=Sophos;i="4.21,423,1188770400"; d="scan'208";a="5873479" Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by mail3-smtp-sop.national.inria.fr with ESMTP; 16 Nov 2007 02:51:43 +0100 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id D33B14837A; Thu, 15 Nov 2007 20:51:41 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 15 Nov 2007 20:51:41 -0500 X-Sasl-enc: 0/5sd9nf94BUNuF0W05BMKD+iSdcXRq/077loSGt4pmI 1195177901 Received: from [192.168.1.11] (AMontsouris-753-1-15-228.w90-2.abo.wanadoo.fr [90.2.199.228]) by mail.messagingengine.com (Postfix) with ESMTP id CE9372A5B1; Thu, 15 Nov 2007 20:51:40 -0500 (EST) Date: Fri, 16 Nov 2007 02:51:19 +0100 (CET) From: Martin Jambon X-X-Sender: martin@martin.ec.wink.com To: Yaron Minsky Cc: Pierre Weis , caml-list , Alain Frisch Subject: Re: [Caml-list] Compiler feature - useful or not? In-Reply-To: <891bd3390711151630x238b8eddod5b7462d0fa1c735@mail.gmail.com> Message-ID: References: <473A363F.2080301@gmail.com> <891bd3390711131608g48b584a4n6b0ccab95d7de3f3@mail.gmail.com> <20071114075827.GA24058@yquem.inria.fr> <473AEC04.3030303@frisch.fr> <20071114143524.GA4423@yquem.inria.fr> <473B249D.9040703@frisch.fr> <20071114184352.GB28796@yquem.inria.fr> <473BE750.9060301@frisch.fr> <20071115132649.GB15754@yquem.inria.fr> <891bd3390711151630x238b8eddod5b7462d0fa1c735@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam: no; 0.00; ens-lyon:01 compiler:01 yaron:01 minsky:01 trivial:01 struct:01 sig:01 val:01 val:01 sig:01 constructors:01 read-only:01 arrays:01 variants:01 variants:01 On Thu, 15 Nov 2007, Yaron Minsky wrote: > Most of what you said about quotient types made sense to me, but I must > admit to being deeply confused about the nature of the change to the > language. Consider the following trivial module and two possible > interfaces. > > module Int = struct > type t = int > let of_int x = x > let to_int x = x > end > > module type Abs_int = sig > type t > val of_int : int -> t > val to_int : t -> int > end > > module type Priv_int = sig > type t = private int > val of_int : int -> t > val to_int : t -> int > end > > So, what is the difference between (Int : Abs_int) and (Int : Priv_int)? Just like for other constructors of concrete types, "private" makes them read-only, i.e. you can use them only in pattern-matching. You can write match (x : Priv_int.t) with 0 -> true | _ -> false But not (x : Priv_int.t) = 0 > For instance, can I write (Priv_int.of_int 3) + (Priv_int.of_int 5)? No, Priv_int would have to define its own Priv_int.(+) function. > Can > you point to anything concrete I can do with the private version that I > can't do with the abstract version? Is there any expression that is legal > for one but not for the other? You can do some pattern-matching over private versions of ints, strings, chars, arrays, builtin lists, polymorphic variants, in addition to records and variants, without the risk of passing such values to the wrong function (if such wrong function expects a real "int" for instance). You can't do any useful pattern matching with abstract types. Martin -- http://wink.com/profile/mjambon http://martin.jambon.free.fr