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 DAA16671; Sat, 23 Oct 2004 03:49:24 +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 DAA16038 for ; Sat, 23 Oct 2004 03:49:23 +0200 (MET DST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i9N1nMtJ032393 for ; Sat, 23 Oct 2004 03:49:23 +0200 Received: by rproxy.gmail.com with SMTP id 79so207338rnk for ; Fri, 22 Oct 2004 18:49:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=dJeFmO3bqJjHgJ4U1iFonbQ/L5uY2zzWjcGYNJo1UrFgTtbJZsH+ABz44h7eAMk0QlR/kynAHgJqI+Ywx4fTGHlS6gDJPX4q8/LXDp7L3Kbd4s8+3Rjczkdxro5hNGRnvjCCpFlHdrL7iJfDg7OUVPcUm33vft4bfvpjt0+AdKI= Received: by 10.38.15.13 with SMTP id 13mr20999rno; Fri, 22 Oct 2004 18:49:22 -0700 (PDT) Received: by 10.38.65.58 with HTTP; Fri, 22 Oct 2004 18:49:22 -0700 (PDT) Message-ID: Date: Fri, 22 Oct 2004 18:49:22 -0700 From: Nathaniel Gray Reply-To: Nathaniel Gray To: caml-list@inria.fr Subject: [Caml-list] Single-case union types as strong typedefs Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4179B8A2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; typedefs:01 degenerate:01 conceptually:01 heights:99 mult:01 mult:01 api:01 atomically:01 foo:01 foo:01 expr:01 expr:01 inlining:01 checker:01 conceptual:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hi, Since we're talking about degenerate cases (unit vs. void) I might as well ask a question that's been on my mind for a while. There are many times when you have types that are structurally identical but conceptually different. One example is lengths measured in different units, another is values measured in identical units that shouldn't be mixed unintentionally (e.g. widths and heights). It would be really nice to be able to use a coding style like this (contrived) example that you could imagine coming from a graphics library: (* Library code: *) type relative_pos = Rpos of int * int type absolute_pos = Apos of int * int let displacement (Apos (x1, y1)) (Apos (x2, y2)) = Rpos(x2 - x1, y2 - y1) let scaled_move (Apos (x1, y1)) (Rpos (x2, y2)) mult = Apos(x1 + x2*mult, y1 + y2*mult) (* Client code: *) let p1 = Apos (5,5) in let p2 = Apos (7,9) in (* Uh-oh, I didn't read the API docs! *) scaled_move p1 p2 5 The idea is that the programmer isn't allowed to mix relative and absolute positions without being explicit about it. Essentially this is a strong typedef. This is all legal right now, but the problem is performance since the tuples get boxed unnecessarily. But non-polymorphic single-case union types can always be optimized away. Or rather, once type checking is complete it's safe to (globally and atomically) perform the group of transformations: type x = Foo y --> type x = y (* Only necessary if types are retained after type checking *) Foo x --> x match x with Foo y -> expr --> let y = x in expr Once this was done, inlining would probably catch any small conversion functions, eliminating any overhead associated with this coding style. So you get the type checker helping you eliminate conceptual bugs with little-to-no run time penalty. So my question is, does the OCaml compiler optimize monomorphic single-case union types this way? If not, is there a conceptual problem with my argument or is it just a lack of time and/or interest? Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ------------------- 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