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 PAA05730; Fri, 6 Apr 2001 15:52:50 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA05726 for ; Fri, 6 Apr 2001 15:52:49 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f36Dqf507757; Fri, 6 Apr 2001 15:52:41 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA05722; Fri, 6 Apr 2001 15:52:42 +0200 (MET DST) Date: Fri, 6 Apr 2001 15:52:41 +0200 From: Xavier Leroy To: Patrick M Doane Cc: Chris Hecker , caml-list@inria.fr Subject: Re: [Caml-list] variant with tuple arg in pattern match? Message-ID: <20010406155241.D5178@pauillac.inria.fr> References: <4.3.2.7.2.20010404034802.0334fae0@shell16.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from patrick@watson.org on Wed, Apr 04, 2001 at 03:18:38PM -0400 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [ Difference between "type foo = Foo of int * int" and "type foo = Foo of (int * int)" ] > I would certainly like it if Caml could: > > 1) Treat this entirely as an optimization issue and not make a syntactic > distinction. This is extremely hard to do in the presence of modules and abstract type. The problem is that the structure struct type foo = Foo of int * int type arg = int * int ... end would then match sig type arg type foo = Foo of arg ... end and users of the module would believe that "Foo" is a constructor with one argument (that happens to be a pair), which does not match the representation used in the rest of the structure ("Foo" as a constructor with two arguments). Type-based compilation strategies such as TAL and FLINT can deal with this issue, but at considerable cost in complexity of the compiler and execution speed. Frankly, I think there is no point in maintaining the illusion that datatype constructors are either nullary (constant) or unary. The only efficient implementation model is N-ary constructors, so let's reflect this in the language. > 2) Be able to make reasonable choices about which representation would > be more appropriate. 99% of the time, the current representation choice (N-ary constructor if the constructor is declared with a N-tuple type) is adequate. I agree that in an ideal world the syntax of the declaration should make this more explicit, e.g. the CamlP4 way ("Foo of int and int" vs. "Foo of int * int"). The current "syntactic overloading" of "*" in constructor declarations is sometimes misleading, but did make the conversion from Caml V3.1 code convenient a long, long time ago... - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr