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 QAA20468; Fri, 22 Oct 2004 16:02:32 +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 QAA20547 for ; Fri, 22 Oct 2004 16:02:31 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i9ME2ScM013625 for ; Fri, 22 Oct 2004 16:02:30 +0200 Received: from [192.168.1.200] (ppp217-99.lns1.syd3.internode.on.net [203.122.217.99]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i9ME2Q4Y084823; Fri, 22 Oct 2004 23:32:26 +0930 (CST) Subject: Re: [Caml-list] Polymorphism and the "for" loop From: skaller Reply-To: skaller@users.sourceforge.net To: Jon Harrop Cc: caml-list In-Reply-To: <200410220838.49340.jon@jdh30.plus.com> References: <1098425963.7584.9.camel@pelican.wigram> <200410220838.49340.jon@jdh30.plus.com> Content-Type: text/plain Message-Id: <1098453745.7584.58.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 Oct 2004 00:02:26 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 417912F4.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 sourceforge:01 2004:99 38,:01 optimised:01 extensional:01 degenerate:01 generalise:01 functor:01 optimise:01 optimise:01 optimised:01 9660:01 glebe:01 compiler:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 2004-10-22 at 17:38, Jon Harrop wrote: > Surely a "procedure" > returns no information, which can be achieved by returning the only value > from a type representing a singleton set, i.e. _the_ value of the type unit. Clearly is can, since that what Ocaml does. But as I pointed out it fails to prevent certain abuses. > > type void = [] > > Why not "`void"? Because `void is a value so if you write: type void = [`void] all you've done is define a non-canonical unit, which is categorically *not* a void :) > I've been wondering about this recently: how do the compilers store types > which contain "unit". If the compiler is smart it just optimises it away. Felix usually optimises it away. In Ocaml, it can't always be optimised away: > For example, if we have a tree: > > type 'a 'b tree = Leaf of 'a | Node of 'b * 'a 'b tree * 'a 'b tree > > Does a "unit unit tree" take up less space than a "int int tree"? No, this isn't possible usually, because any polymorphic algorithm using this data structure expects a fixed layout in memory. So in this case, a dummy value must exist. This problem can't arise in Felix or C++, because they both use extensional polymorphism (compile time instantiation). The only way this might work in Ocaml is if the pointer to value was replaced by NULL, but that would require a NULL check, and slow down the algorithm for all types just to save some memory in degenerate cases. > The reason I'm asking is that it might be nice to generalise data structures > as much as possible and then specialise them using "unit" arguments. If you use a functor, the compiler might be able to optimise it away. I think you can assume most uses like this: let f () = ... f () actually don't pass the () around: that's such an obvious thing to optimise. Still, there must be a version of f that isn't optimised, otherwise you couldn't pass it to a higher order function. -- 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