From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p2SCduIf032321 for ; Mon, 28 Mar 2011 14:39:56 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAEaBkE1V2gB5mWdsb2JhbAClVAECAQgLEhQliGu5fg2FXASQZQ X-IronPort-AV: E=Sophos;i="4.63,255,1299452400"; d="scan'208";a="95150757" Received: from emailfrontal2.citycable.ch ([85.218.0.121]) by mail2-smtp-roc.national.inria.fr with SMTP; 28 Mar 2011 14:39:50 +0200 X-Alinto-smtpauth-localdomain: Yes Received: from seldon (unknown [85.218.93.111]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal2.citycable.ch (Postfix) with ESMTPA id 8B97F20C6C6; Mon, 28 Mar 2011 14:39:49 +0200 (CEST) Received: from yziquel by seldon with local (Exim 4.72) (envelope-from ) id 1Q4Bix-0003PU-2e; Mon, 28 Mar 2011 14:39:11 +0200 Date: Mon, 28 Mar 2011 14:39:10 +0200 From: Guillaume Yziquel To: Alain Frisch Cc: David Allsopp , caml-list Message-ID: <20110328123910.GC20598@localhost> References: <639CCD2C-402F-4754-B942-B460FD908A95@gmail.com> <63968844-AD95-4359-80F0-E9E071CF6518@mpi-sws.org> <20110325164240.GT10028@localhost> <46B666E2-4575-4E79-ACF1-FE0789C0C76B@mpi-sws.org> <20110325190129.GU10028@localhost> <4D903E90.4080907@frisch.fr> <20110328103325.GH20598@localhost> <20110328115831.GW20598@localhost> <4D907DD6.2030507@frisch.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4D907DD6.2030507@frisch.fr> User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p2SCduIf032321 Subject: Re: [Caml-list] Re: module typing issue Le Monday 28 Mar 2011 à 14:23:50 (+0200), Alain Frisch a écrit : > On 03/28/2011 01:58 PM, Guillaume Yziquel wrote: > >Yes an no. From a type inference perspective, that's right. However, you > >can already do such pattern matching on private row types for variant > >types. > > > >module X : sig > > type t = private [< `A ] > > val x : t > >end = struct > > type t = [ `A ] > > let x = `A > >end > > > >match X.x with `A -> () > > > >and the X.x is correctly unified with `A. So the type inference issue is > >solved in this case. > > Private row types are not the same as private type abbreviations. > The syntax might be a source of confusion here, but the keyword > "private" really means three different things: Yes. I just find it too bad that the distinction between these three different 'private' types is so neat. > - Private type declarations: constructors/labels are available for > deconstructing values (pattern matching, dot notation), not for > building values. That's where I'd like type t = private int to stand at times. Having it as a private type abbreviation is sometimes too strong. > - Private type abbreviations (where the abbreviated type is not an > object type or a polymorphic variant type): the behavior is very > much the same as an abstract type, except that the abbreviation is a > subtype of the abbreviated type (and the compiler can use the > concrete type to choose a runtime representation of -- e.g. for > records of floats -- and to trigger optimizations). Yes. I'm just sad that when you have predefined pattern-matching way to deal with a type (such as strings or ints), these private type abbreviations drop the deconstructing features of private type declarations. > - Private row types: you can think of the 'private' annotation as a > way to name (as an abstract type) the implicit row type variable of > the abbreviated type. There is no hiding as for type abbreviation > and no access control as for private type declarations. Yes. And in a signature, you can replace them with the 'with type :=' construct. This is again different, and also handy. > The syntax for private type abbreviation and private row types is > the same; they are distinguished only in the type-checker. As far as > I know, there is no way to create a private type abbreviation on a > object or variant type. Except than aliasing the object or variant type to another type and doing a private type abbreviation on the alias. > Alain -- Guillaume Yziquel