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.9 required=5.0 tests=AWL,SPF_SOFTFAIL 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 8FFCCBC6C for ; Fri, 16 Nov 2007 16:08:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKdAPUdCbwQZnmdsb2JhbACPDQEBAQEHBAYpgQ8 X-IronPort-AV: E=Sophos;i="4.21,426,1188770400"; d="scan'208";a="4576545" Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by mail1-smtp-roc.national.inria.fr with ESMTP; 16 Nov 2007 16:08:32 +0100 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 349D746EB9; Fri, 16 Nov 2007 10:08:31 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 16 Nov 2007 10:08:31 -0500 X-Sasl-enc: QgmboeeJq7s96m9K4GNJSOPgVbiamY7gbo365xyabjm+ 1195225710 Received: from [192.168.1.11] (unknown [90.46.0.137]) by mail.messagingengine.com (Postfix) with ESMTP id 8021AF067; Fri, 16 Nov 2007 10:08:30 -0500 (EST) Date: Fri, 16 Nov 2007 16:08:23 +0100 (CET) From: Martin Jambon X-X-Sender: martin@martin.ec.wink.com To: Alain Frisch Cc: caml-list Subject: Re: [Caml-list] Compiler feature - useful or not? In-Reply-To: <473D61A3.9090708@frisch.fr> 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> <473D61A3.9090708@frisch.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam: no; 0.00; ens-lyon:01 compiler:01 frisch:01 ocaml's:01 cvs:01 ocaml:01 notation:01 val:01 bool:01 integers:01 algebra:01 well-typed:01 ill-typed:01 type-based:01 subtyping:01 On Fri, 16 Nov 2007, Alain Frisch wrote: > Martin Jambon wrote: >> You can write >> match (x : Priv_int.t) with 0 -> true | _ -> false > > Actually, you cannot do that, at least with private types as implemented in > OCaml's CVS. And this is to be expected given the lack of implicit > subsumption in OCaml. If you were able to do such a thing, what type schema > would you give to: > > let f = function 0 -> true | _ -> false > > ? Using the notation for polymorphic variant types: val f : [< int ] -> bool Type [> int ] would be the same as [ int ] or int. > This function should work on integers as well as on values of type > Priv_int.t, but the type algebra cannot express that. > > My understanding (Pierre will correct me if I'm wrong) is that private type > abbreviations, as they are currently implemented, can always be replaced by > abstract types without turning a well-typed program into an ill-typed one. > Doing so will prevent some type-based optimizations to happen, though. > > But the really interesting thing is that the new feature opens the door to > extending the subtyping operator :> to take into account the natural > (identity) injection from a private abbreviation to the underlying type. This > is especially useful when the value of the private type appears deeply nested > in a structure. With a normal function that implements the injection, you > need to lift it to the whole structure which forces useless copies (and > worse: the manual lifting may not be possible if some module declares a > covariant type without a corresponding map function). > > For instance: > > (l : (Priv_int.t * Priv_int.t) list :> (int * int) list) > > instead of > > List.map (fun (x, y) -> (Priv_int.to_int x, Priv_int.to_int y)) l Thanks, this is clear now. -- http://wink.com/profile/mjambon http://martin.jambon.free.fr