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 HAA14016; Sun, 24 Oct 2004 07:18:58 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 HAA14584 for ; Sun, 24 Oct 2004 07:18:57 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i9O5Is1A028612 for ; Sun, 24 Oct 2004 07:18:56 +0200 Received: from [192.168.1.200] (ppp217-99.lns1.syd3.internode.on.net [203.122.217.99]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i9O5IlOU053132; Sun, 24 Oct 2004 14:48:48 +0930 (CST) Subject: Re: [Caml-list] Single-case union types as strong typedefs From: skaller Reply-To: skaller@users.sourceforge.net To: Nathaniel Gray Cc: Jacques Garrigue , caml-list In-Reply-To: References: <20041023.123139.106410806.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain Message-Id: <1098595127.7584.219.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 24 Oct 2004 15:18:47 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 417B3B3E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 typedefs:01 sourceforge:01 2004:99 2004:99 jacques:01 unlucky:01 boxing:01 1,3:01 1,3:01 optimised:01 jacques:01 optimising:01 problem':01 'only:99 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2004-10-24 at 07:24, Nathaniel Gray wrote: > On Sat, 23 Oct 2004 12:31:39 +0900 (JST), Jacques Garrigue > wrote: > > > Unlucky! > > With your example, there is no extra boxing involved. > > I.e. (1,3) and Rpos(1,3) and Apos(1,3) all share the same physical > > representation (a block with 2 fields). > > The problem you describe only occurs when your single constructor has > > only one argument. > > Really?? You're kidding. That's kind of cool but kind of strange -- > why does it only optimize for composite types? For two arguments, it's a pointer to a pair on the heap. For one, its a pointer to a one element tuple on the heap. This case might be optimised by replacing the pointer with the value stored in that single field, but it isn't. That's what Jacques meant -- there's no issue of optimising the composite case, so there is 'no problem' then, the problem 'only occurs when .. has only one argument' because that's the only time you might get rid of the extra level of indirection. Note this would only be possible for the single constructor with one argument, because the tag field (for the variant case) stored on the heap is lost too, but it isn't needed for the single constructor case. It isn't needed for the composite argument case either .. but a heap block is needed for the tuple, so the tag field is there anyhow. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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