From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA20087; Wed, 8 Oct 2003 19:04:56 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA07260 for ; Wed, 8 Oct 2003 19:04:55 +0200 (MET DST) Received: from hugh.cs.washington.edu (hugh.cs.washington.edu [128.208.2.43]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h98H4s106124 for ; Wed, 8 Oct 2003 19:04:54 +0200 (MET DST) Received: from cs.washington.edu (gerald.cs.washington.edu [128.208.2.33]) by hugh.cs.washington.edu (8.12.9/8.12.9/1.2+) with ESMTP id h98H4rwT023892; Wed, 8 Oct 2003 10:04:53 -0700 (envelope-from djg@cs.washington.edu) X-Authentication-Warning: hugh.cs.washington.edu: Host gerald.cs.washington.edu [128.208.2.33] claimed to be cs.washington.edu Message-ID: <3F8443C1.6030404@cs.washington.edu> Date: Wed, 08 Oct 2003 10:05:05 -0700 From: Dan Grossman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andreas Rossberg CC: caml-list@inria.fr Subject: Re: [Caml-list] Constructors as functions and tuples in constructors References: <3F843648.3030200@cs.washington.edu> <3F843C6E.8060407@ps.uni-sb.de> In-Reply-To: <3F843C6E.8060407@ps.uni-sb.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; grossman:01 caml-list:01 allocating:01 --dan:01 rossberg:01 grossman:01 parens:01 compiler:01 compiler:01 workaround:01 int:01 int:01 constructors:01 constructors:01 trivial:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk A good point, with these rebuttals: (1) A pattern-match would have the potential of allocating memory, which some may judge poorly. But the compiler could warn about this. (2) This transformation does require the type A carries is transparent. So we still couldn't relax the "other" restriction that a signature cannot hide an unparenthesized t1 * t2 variant. (3) It's not clear how far this trivial transformation should be generalized. For example, given type t = A of int * int * int * int which of these should we allow A(1,2,3,4) A((1,2,3,4)) A((1,2),(3,4)) A(1,(2,3),4) ... --Dan Andreas Rossberg wrote: > Dan Grossman wrote: > >> >>> Second, it would also be nice not to have "the concept of constructor >>> arity", and treat the code below as correct: >>> >>> type t = A of int * int >>> let _ = match A (17, 0) with >>> A z -> match z with (x, y) -> () >> >> >> Works with type t = A of (int * int). You put the parens in. So the >> choice is yours. The advantage of leaving them out is usually >> performance. > > > That is not true. It would be quite trivial for the compiler to translate > > A z -> e > > into the equivalent of > > A(z1,z2) -> let z = (z1,z2) in e > > without affecting performance of other programs in any way. Likewise, > > A z > > could be transformed into > > let (z1,z2) = z in A(z1,z2) > > instead of rejecting it. OTOH, your workaround certainly decreases > performance for type t, as other pointed out. > ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners