From: Nathaniel Gray <n8gray@gmail.com>
To: caml-list@inria.fr
Subject: [Caml-list] Single-case union types as strong typedefs
Date: Fri, 22 Oct 2004 18:49:22 -0700 [thread overview]
Message-ID: <aee06c9e041022184937006109@mail.gmail.com> (raw)
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
next reply other threads:[~2004-10-23 1:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-23 1:49 Nathaniel Gray [this message]
2004-10-23 3:31 ` Jacques Garrigue
2004-10-23 3:39 ` David Brown
2004-10-23 5:00 ` skaller
2004-10-23 21:49 ` Nathaniel Gray
2004-10-23 21:24 ` Nathaniel Gray
2004-10-23 21:33 ` Nathaniel Gray
2004-10-24 3:00 ` John Prevost
2004-10-24 5:18 ` skaller
2004-10-24 22:52 ` Nathaniel Gray
2004-10-25 13:21 ` Damien Doligez
2004-10-25 14:25 ` Jacques Carette
2004-10-26 14:07 ` Damien Doligez
2004-10-26 15:05 ` Jacques Carette
2004-10-26 17:34 ` skaller
2004-10-26 20:02 ` [Caml-list] Combined compilation and linking Jon Harrop
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aee06c9e041022184937006109@mail.gmail.com \
--to=n8gray@gmail.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox