On Sat, 23 Oct 2004 12:31:39 +0900 (JST), Jacques Garrigue
<garrigue@kurims.kyoto-u.ac.jp> wrote:

> Unlucky!
> With your example, there is no extra boxing involved.
> I.e. (1,3) and Rpos(1,3) and Apos(1,3) all share the same physical
> representation (a block with 2 fields).
> The problem you describe only occurs when your single constructor has
> only one argument.

Really??  You're kidding.  That's kind of cool but kind of strange --
why does it only optimize for composite types?

> Indeed, this would be nice to have the overhead compiled away.
> I don't remember whether there was a concrete reason not to.
> At least one reason could be that if you add a new constructor later, you
> will not be able to read dumped values of the previous type anymore,
> but this doesn't seem a very strong reason.

I would say not -- the whole point of using such a type would be that
it only has one constructor so adding another would not be likely.

> Note that Haskell has a special notation for this case, using "newtype"
> rather than "type" or "data", which marks explicit this as a special
> case.

That's a perfectly fine approach, but I prefer the single-constructor
union approach because there are no new concepts, just optimizations.

Cheers,
-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