Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Single-case union types as strong typedefs
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Nathaniel Gray <n8gray@g...>
Subject: [Caml-list] Single-case union types as strong typedefs
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