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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id F2B5CBBC4 for ; Fri, 17 Apr 2009 23:12:35 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQEADOO6EnZSMDdjmdsb2JhbACBTpRrAQEBAQkLCAkPBbhfg30G X-IronPort-AV: E=Sophos;i="4.38,431,1233529200"; d="scan'208";a="27870685" Received: from fmmailgate01.web.de ([217.72.192.221]) by mail1-smtp-roc.national.inria.fr with ESMTP; 17 Apr 2009 23:12:14 +0200 Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate01.web.de (Postfix) with ESMTP id B0A331002C17E; Fri, 17 Apr 2009 23:12:13 +0200 (CEST) Received: from [78.43.226.218] (helo=frosties.localdomain) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1LuvM5-0001X0-00; Fri, 17 Apr 2009 23:12:13 +0200 Received: from mrvn by frosties.localdomain with local (Exim 4.69) (envelope-from ) id 1LuvM4-0004ab-EX; Fri, 17 Apr 2009 23:12:12 +0200 From: Goswin von Brederlow To: "David Allsopp" Cc: "'Goswin von Brederlow'" , "'Pal-Kristian Engstad'" , , Subject: Re: [Caml-list] pattern matching and records vs tuples References: <87skkbuxx8.fsf@aryx.cs.uiuc.edu> <891bd3390904141744k4516f3d0y551f6c572ccadad5@mail.gmail.com> <49E53C8A.1090601@naughtydog.com> <87tz4opori.fsf@frosties.localdomain> <000b01c9beb4$ac3d50a0$04b7f1e0$@com> Date: Fri, 17 Apr 2009 23:12:12 +0200 In-Reply-To: <000b01c9beb4$ac3d50a0$04b7f1e0$@com> (David Allsopp's message of "Thu, 16 Apr 2009 17:59:13 +0100") Message-ID: <87skk72deb.fsf@frosties.localdomain> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX1/aOWcaczTqjAOxzfkPnkCD43hW+7K7VKGH3+mF knTpz3OQcPAaIkVEDQIIu1yhZ9sAPt15QdC+R0C4RQrAf8vAz/ hGZiyCk8I= X-Spam: no; 0.00; subtype:01 val:01 subtypes:01 subtype:01 val:01 bindings:01 segfault:01 runtime:01 bindings:01 ocaml:01 ocaml:01 totaly:98 alterations:98 mfg:98 sml:01 "David Allsopp" writes: > 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. Yes. They don't share a common prefix except the empty one. >> 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 Why? If you declare the binding as { x : int } as 'a -> 'a then it works just like now. If you declare it as { x : int; .. } as 'a -> 'a then it has to cope with super types. That is totaly up to you (as writer of the bindings) to decide and to ensure. Ocaml should probably provide a copy_record or clone_record helper function to simplify { r with x = 1 } type alterations in C. > 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 MfG Goswin