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 KAA06391; Fri, 22 Oct 2004 10:06:38 +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 KAA05673 for ; Fri, 22 Oct 2004 10:06:37 +0200 (MET DST) Received: from mail.davidb.org (adsl-64-172-240-129.dsl.sndg02.pacbell.net [64.172.240.129]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i9M86YPS000958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Oct 2004 10:06:36 +0200 Received: from davidb by mail.davidb.org with local (Exim 4.42 #1 (Debian)) id 1CKuRW-0008CQ-1I; Fri, 22 Oct 2004 01:06:34 -0700 Date: Fri, 22 Oct 2004 01:06:34 -0700 From: David Brown To: Jon Harrop Cc: caml-list Subject: Re: [Caml-list] Polymorphism and the "for" loop Message-ID: <20041022080634.GA31350@old.davidb.org> References: <1098425963.7584.9.camel@pelican.wigram> <200410220838.49340.jon@jdh30.plus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410220838.49340.jon@jdh30.plus.com> User-Agent: Mutt/1.5.6i X-Miltered: at nez-perce with ID 4178BF8B.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 caml-list:01 2004:99 n-tuples:01 triples:01 -tuple:01 generalise:01 compilers:01 ocaml:01 int:01 int:01 side-effects:02 node:02 node:02 tree:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, Oct 22, 2004 at 08:38:49AM +0100, Jon Harrop wrote: > I've been wondering about this recently: how do the compilers store types > which contain "unit". 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"? Each of the types 'Leaf', or Node will always take the same amount of space, not counting the header (which is 1 word before the block): A leaf will be 1 word, and a Node will be 2 words. The value passed around is always a word, which fits in a pointer. So a "unit unit tree" of the same shape takes up the same space as an "int int tree". However, if the type doesn't fit in a word, heap space will be needed for the block. In ocaml, (), the only value of type unit, is always represented as the word '1'. The unit type follows nicely from the pattern of n-tuples (pairs, triples, 4-typles, so why not 0-tuples). The unit value is really a 0-tuple. Since the type is parameterized by 0 other types, there is only one unit type. > 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. But, the original discussion was concerning procedures that don't actually return anything. Without side-effects, procedures aren't useful, since they can't do anything. Since there are side effects, though, it is meaningful to have a procedure that doesn't return any type. The unit type was created for this purpose. If we created another type, say void, to indicate a function that returned no value (a procedure), it would mostly serve the same purpose as the unit type. It might be possible to avoid having a constructor for this type, but then it gets more difficult to explicitly ignore values. I think you would quickly get back to the same place we are at now. Perhaps 'unit' is fine for functions that don't return anything, and we should come up with something different to pass in as the needed argument to functions that don't need an argument. You could always create type noarg = Noarg another single-constructor type, and use noarg for functions that don't really want an argument. This would prevent you from calling this function with the result of something that wasn't intended to return a value. I guess my question is, for functions that takes unit, and returns unit, what's really wrong with: f (g ()) The evaluation order is defined, although not necessarily meaningful. Perhaps later I might want to come up with a value that gets passed from g to f. Dave ------------------- 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