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.0 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 CD620BBC4 for ; Thu, 16 Apr 2009 18:59:20 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwCADsA50lRZ90wlGdsb2JhbACOLod4AQEBAQkLCAkRA7p3g30G X-IronPort-AV: E=Sophos;i="4.40,199,1238968800"; d="scan'208";a="26364661" Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by mail3-smtp-sop.national.inria.fr with ESMTP; 16 Apr 2009 18:59:20 +0200 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090416165919.UQEP4080.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Thu, 16 Apr 2009 17:59:19 +0100 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090416165918.QJJY13254.aamtaout01-winn.ispmail.ntl.com@romulus.metastack.com>; Thu, 16 Apr 2009 17:59:18 +0100 Received: from Tenor ([172.16.0.9]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id n3GGxFmo018643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Apr 2009 17:59:16 +0100 From: "David Allsopp" To: "'Goswin von Brederlow'" , "'Pal-Kristian Engstad'" Cc: , References: <87skkbuxx8.fsf@aryx.cs.uiuc.edu> <891bd3390904141744k4516f3d0y551f6c572ccadad5@mail.gmail.com> <49E53C8A.1090601@naughtydog.com> <87tz4opori.fsf@frosties.localdomain> In-Reply-To: <87tz4opori.fsf@frosties.localdomain> Subject: RE: [Caml-list] pattern matching and records vs tuples Date: Thu, 16 Apr 2009 17:59:13 +0100 Organization: MetaStack Solutions Ltd. Message-ID: <000b01c9beb4$ac3d50a0$04b7f1e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+rTtI0Qn808QWTOCAUk2+tAFxjgABJfyA Content-Language: en-gb X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77 X-Cloudmark-Analysis: v=1.0 c=1 a=sE5NrYb5UfYA:10 a=8egov0mC6psA:10 a=TAx1SOch8d5yAxZK3LcA:9 a=dwFDedIPNUiPmGZKWuGhLGVtO_QA:4 X-Spam: no; 0.00; subtype:01 val:01 subtypes:01 subtype:01 val:01 bindings:01 segfault:01 runtime:01 ocaml:01 sml:01 sml:01 wrote:01 caml-list:01 tuples:01 coercion:01 Goswin von Brederlow wrote: > I would actually like to propose that to work on a type > level. Currently we have: > > I propose that records can be subtyped if their prefix matches and > ".." would be used to denote the subtype of any record with this > prefix: > > One could also declare get_x to accept supertypes: > > # let get_x (r : { x : int; .. }) = r.x; > val get_x : { x : int; .. } -> int = > > # get_x { x=1; y=2; };; > - : int = 1 Bear in mind that for this work the label must be at the same ordinal position within both record types for this to work (which I think could potentially be irritating). For example, given: # type base = { x : int } let get_x r = r.x type more = { y : int; x : int };; # get_x ({ y=2; x=1; } :> base);; You would have to get a type coercion error message. > I think there is only one thing that would need to be changed for the > compiled code with record subtypes like the above. Copying and > modifying a record would need allocate a block matching the size of > the input record and not the size of the subtype. Think about this > code: > > # let change_x (r : { x : int; .. }) x = { r with x = x } > val change_x : { x : int; .. } as 'a -> int -> 'a = > # change_x { x=1; y=2; } 2;; > - : more = {x = 2; y = 2} I imagine that it's a reasonably rare thing to do, but any C bindings which manipulate record types in this way would break (and probably segfault the runtime) if this behaviour were required. The other worry in the back of my mind is that despite having considerably more flexible records in SML (you don't have to declare the types in advance and label sharing is possible), a function in SML still has the restriction of only being over a fixed record type ... and when SML has odd restrictions, they're usually to do with the more "obvious" type system feature being undecideable. For example, you can't say in SML: fun get_x r = #x r; as the equivalent of the OCaml get_x you propose. David