From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q3CH7X6N018642 for ; Thu, 12 Apr 2012 19:07:35 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQBAJ8Lh0+DbwiWmWdsb2JhbABDugIiAQEBAQEICwsHFCeCCgEFOEEQAQpGVwaIIQS1ZIEhkX4Em16NLA X-IronPort-AV: E=Sophos;i="4.75,411,1330902000"; d="scan'208";a="153781362" Received: from ppsw-50.csi.cam.ac.uk ([131.111.8.150]) by mail1-smtp-roc.national.inria.fr with ESMTP; 12 Apr 2012 19:07:31 +0200 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41564) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:lpw25) id 1SINUZ-0002B8-py (Exim 4.72) (return-path ); Thu, 12 Apr 2012 18:07:31 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:lpw25) id 1SINUZ-00027M-1D (Exim 4.67) (return-path ); Thu, 12 Apr 2012 18:07:31 +0100 Received: from [86.26.0.34] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 12 Apr 2012 18:07:30 +0100 Date: 12 Apr 2012 18:07:30 +0100 From: Leo P White To: Gabriel Scherer Cc: caml Message-ID: In-Reply-To: References: X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: "L.P. White" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q3CH7X6N018642 Subject: Re: [Caml-list] [ANN] ocamlopen 1.0.2 >1. You link to a paper by Andres Löh and Ralf Hinze, how close are you >of their proposal? >They mention open datatypes and functions, you propose open datatypes, >but not open functions? That would be understandable because open >pattern matching is a bit fishy (best-fit matching etc...). I think that my open datatypes are basically the same as they propose, which is pretty much the same as the behaviour of exn in OCaml. >2. What is the difference between your "open" and "extensible" >datatypes? The visual difference is the present of initial >constructors in extensible cases, but you apparently make much finer >distinctions. This complication arises from the existence "extensible variant declarations", and is one of the reasons that I think the extension is probably better without them. Basically, by an "extensible" type I mean one for which not all the constructors are given in the type declaration. Obviously all abstract types in a signature are extensible, because they may be implemented using a variant type. My extension allows variant type declarations to also be made extensible using the syntax: type Foo = A | B of int | .. Note that this extensibility cannot be hidden by a signature, the compiler needs to know if a variant is extensible in order to properly implement pattern matching. By an "open" type I mean one that is allowed to be extended using an extension definition. Only extensible types can be declared open, becuase an extension definition adds constructors to a type that are not mentioned in its declaration. Unlike extensibility, the openness of a type can be hidden using a signature. >3. What is the semantics of making a *constructor* private? My >intuition of private types is that (type t = private u) generates a >new type t that is a strict subtype of u (values of type t can be >coerced into u, but not the other way around). This intuition does not >hold anymore if some constructors are marked private, but not the >other. As Alain said, making a constructor private allows it to be used for pattern matching but not to create a value. This is an alternative intuition for how private variant types already work. I think that allowing private extensions could definitly be useful. Borrowing Alain's example of a messsage bus, if a message producer used a private message constructor then it could enusre that it was the only component producing messages with that constructor. Note that the extension does not allow private abstract types to be declared open, because this would break the standard intuition for them. However, it does allow private variant declarations to be made open and treats this as meaning that each of its ordinary constructors is private, but that public extensions *can* still be created and used in positive positions. I think that this is a bit of a muddle, and possibly another reason that extensible variant declarations should be left out. >4. When would you say that one should use polymorphic variants rather >than your open datatypes? (I know how to argue in the other direction: >unique constructors make for better error messages.) A good reason for using polymorphic variants is to create multiple types that share constructors. For instance a compiler might want one type to represent expressions and another to represent constant expressions. Using polymorphic variants constant expression values could be used directly as expressions values. This wouldn't be possible using open datatypes. Note that there are other reasons to use open datatypes over polymorphic variants: they can be used properly with references, they can be controlled using modules and they can be GADTs. >5. What are the implications of your patch at the runtime / data >representation level? Could you elaborate a bit more on "a new tag to >represent extensions"? Have you conducted performance measurements? Just like exceptions, they are represented as constructors whose first field points to an address that is allocated by the extension definition to represent that extension. They have a special tag value so that structural equality knows to compare the first fields by address. Note that this is exactly what is required to fix the bug with structural equality on exceptions (4765). I haven't conducted any performance measurements, but using extensions should be similar in cost to using exceptions. The ordinary variants in an extensible variant declaration should perform similarly to any other ordinary variants. Thanks for the interest. Regards, Leo