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 KAA07750; Mon, 6 Aug 2001 10:21:34 +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 KAA07664 for ; Mon, 6 Aug 2001 10:21:33 +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 f768Ecv09375; Mon, 6 Aug 2001 10:14:38 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA07687; Mon, 6 Aug 2001 10:14:37 +0200 (MET DST) Date: Mon, 6 Aug 2001 10:14:37 +0200 From: Xavier Leroy To: John R Harrison Cc: caml-list@inria.fr, Neel Krishnaswami , Andreas Rossberg , Markus Mottl Subject: Re: [Caml-list] Why can't I use constructors as functions? Message-ID: <20010806101437.D7188@pauillac.inria.fr> References: <200108031627.JAA19052@dhpc0010.pdx.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200108031627.JAA19052@dhpc0010.pdx.intel.com>; from johnh@ichips.intel.com on Fri, Aug 03, 2001 at 09:27:15AM -0700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > | The old Caml V3.1 implementation treated constructors as functions like > | SML. In Caml Light, I chose to drop this equivalence for several reasons: > > I think you're forgetting that at some stage you must have re-introduced > it. You're correct, the "constructor as functions" was implemented in Caml Light version 0.7. Tremendous psychological pressure must have been exerted on me to make me implement this, causing me to forget all about it afterwards :-) > I would be happy to have constructors curried or uncurried, but I don't > see that exposing a distinct notion of arity serves any useful purpose. It serves the following purpose: all implementations want to represent specially a constructor that takes a tuple of arguments, e.g. C of int * int representing it as one block tagged C with two integer fields, rather than the "normal" representation as a block tagged C containing a pointer to a block representing the pair. This optimization is crucial both for memory size (cuts down memory use by a factor of 5/3) and for speed. In combination with modules, it's very hard to perform this representation trick transparently, i.e. as a compiler optimization. The reason is that a module implementation can define type t = C of int * int type u = int * int let f x = (* code assuming that C(x,y) is represented as 1 block *) yet its interface can abstract over u: type u type t = C of u val f : ... and clients of the module assume a different representation for C, namely that it has only one field containing "the" argument of C. Some form of representation coercion or run-time type inspection is necessary to deal with this case, and it can be extremely complex (see the TIL compiler for an example). By exposing a notion of arity for constructors, we prevent the module implementation above from matching the module signature "type t = C of u", thus working around the problem. More generally, I think the representation trick for constructors taking several arguments is so crucial and so hard to perform as a transparent optimization that it deserves to be exposed in the language as a primitive concept of "constructor with arity". > Isn't it conceptually simpler to have constructors behave as regular > objects as much as possible? (Of course, not in pattern matching etc.) As you said, constructors already have a special status in pattern-matching, so it doesn't seem much more conceptually difficult to treat them as a primitive concept distinct (and essentially orthogonal) from functions. - Xavier Leroy ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr