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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 33861BC69 for ; Sat, 24 Feb 2007 19:14:21 +0100 (CET) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l1OIEISx029086 for ; Sat, 24 Feb 2007 19:14:20 +0100 Received: from ppp41-119.lns2.syd6.internode.on.net (HELO rosella) ([59.167.41.119]) by ipmail01.adl2.internode.on.net with ESMTP; 25 Feb 2007 04:44:15 +1030 X-IronPort-AV: i="4.14,215,1170595800"; d="scan'208"; a="92976739:sNHT56753032" Subject: Re: [Caml-list] Feature request : Tuples vs. records From: skaller To: Brian Hurt Cc: Lukasz Stafiniak , caml-list@yquem.inria.fr In-Reply-To: References: <7639252.205431172158497978.JavaMail.www@wwinf2216> <45DDC1CB.2090401@ens-lyon.org> <200702230145.55947.jon@ffconsultancy.com> <4a708d20702230832m4e143586i6036980ead10042a@mail.gmail.com> <4a708d20702240543w4c9d0a91tb12c13b10254a68b@mail.gmail.com> Content-Type: text/plain Date: Sun, 25 Feb 2007 05:14:10 +1100 Message-Id: <1172340850.5345.39.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45E0807A.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; lukasz:01 polymorphism:01 ocaml:01 foo:01 foo:01 syntax:01 typedef:01 endmatch:01 int-:01 endl:01 endmatch:01 recursion:01 lukasz:01 syntax:01 arrays:01 On Sat, 2007-02-24 at 10:50 -0500, Brian Hurt wrote: > > On Sat, 24 Feb 2007, Lukasz Stafiniak wrote: > > > I have this idea... We could have row polymorphism in tuples, without > > any impact on performance! Instead of insisting that ('a * 'b) means > > exactly two elements, we could have (> 'a * 'b) at least two elements. > > Any projections or pattern matching fetches the tuple fields without > > problems: it doesn't need to care that there are more than it needs. > > > > Say you realize that you need to return another value from a function > > (which already returns a tuple): you would only modify the function > > and not its uses. > > Not being able to do this is one of the reasons I *like* Ocaml. > > Consider the case where the calling location is: > let a, b = foo ... in > ... > > Now you change foo to return 3 tuples instead of just 2. What happens? > > If you say "The third element quietly gets dropped", I'll respond with "if > I wanted that behavior, I'd be coding in Perl." I think you're taking his idea too literally: consider instead an explicit syntax which allows tuples to be pattern matched like lists. Felix can actually do this: ///////////////////////////////////////// #import typedef fun xcur(t:TYPE):TYPE => typematch t with | ?a -> ?b => a * xcur b | _ => t endmatch; var x : xcur (int->long->double) = (1,(2L,3.0)); match x with | ?a,(?b,?c) => { print a; print " "; print b; print " "; print c; endl; } endmatch; ////////////////////////////////////////// The thing to note here is that we have a generic pattern match which can fold along the components of a function type using recursion. (This is an example of my version of Jay pattern calculus). But you cannot recurse over a tuple like this because it isn't built up inductively from a binary operator. We can adapt Lukasz suggestion to make it possible, by for example the syntax: head, tail ... or some such, which treats a tuple like a list. Of course such a construction should be *explicit*. Similarly, a version of this could work for arrays: it would be data polymorphic but not generic (since all array elements have the same type). -- John Skaller Felix, successor to C++: http://felix.sf.net