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 q2VJHYPC011505 for ; Sat, 31 Mar 2012 21:17:34 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQCAIZXd0/UGyoDfmdsb2JhbAA5CYMcsmeDByIBAQsHBAsHFAMkggkBAQQBMgEFQAEFCwsYCRYPCQMCAQIBRQYNAQcBAReHaQm2dYsHhhUElWGFcI0o X-IronPort-AV: E=Sophos;i="4.75,349,1330902000"; d="scan'208";a="152084397" Received: from smtp3-g21.free.fr ([212.27.42.3]) by mail1-smtp-roc.national.inria.fr with ESMTP; 31 Mar 2012 21:17:28 +0200 Received: from [192.168.0.11] (unknown [78.192.0.38]) by smtp3-g21.free.fr (Postfix) with ESMTP id A56B7A60FD; Sat, 31 Mar 2012 21:17:24 +0200 (CEST) Message-ID: <4F775844.5000006@frisch.fr> Date: Sat, 31 Mar 2012 21:17:24 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Fran=E7ois_Bobot?= CC: caml-list@inria.fr References: <87fwcx6ejm.fsf@frosties.localnet> <4F74E647.1040603@lri.fr> In-Reply-To: <4F74E647.1040603@lri.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] Wish: mutable variant types, equivalence with records On 3/30/2012 12:46 AM, François Bobot wrote: > But can't we consider that, for a semantic, syntax and typing perspective: > > type t = > | A of string > | B of ({msg: string; mutable foo:int} as t2) > | C > > is exactly the same thing than: > > type t = > | A of string > | B of t2 > | C > > and t2 = {msg: string; mutable foo:int} > > > The only difference is that when you create a record of type t2 the tag > is directly the one of B in the first case and is the default tag for > record (the first tag if I remember well) in the second case. So in the > first case applying the constructor B is just the identity. It is an interesting idea to give an explicit type to the record argument, allowing it to be manipulated as a first-class value. Instead of requiring an explicit name, one could introduce a syntax to refer to the implicit record declaration for a record constructor. For instance, after defining: type t = | A of string | B of {msg:string; mutable foo:int} | C one could refer to the type t/B, which would behave like a normal record type (with a runtime representation such that applying B is the identity). > The only disadvantage, I see, compared to Alain Frisch's proposition is > that two records share with difficulty the same field name. But special > case can be made when we know the record type thanks to the constructor > eg B {x=...}, C {x=...}. We should rather look for a general solution to record field overloading. I think that changes introduced for GADTs in the typing of patterns makes it quite easy to use propagated type information to disambiguate between record types sharing the same field names (and similarly for sum types sharing the same constructor names). Alain