From: malc <malc@pulsesoft.com>

> > # module M = struct type t = float and r = {f:t} end;;
> > # module M' = struct type t = float type r = {f : t} end;;
> > 
> > In the first case, the record is represented as an array of a pointer
> > to a boxed float, while in the second case it is represented as an
> > array of an unboxed float. Since the data representation is different,
> > these two signatures are not equivalent. I was afraid there would be
> > no direct way to express the first case, but actually you can.
> 
> What exactly triggered the switch from boxed to unboxed repersentation?
> I mean, this is completely unobvious and can have severe performance
> degradation, so description of cases when this might happen could be
> useful.

This the use of "and". In mutually recursive type definitions, other
types are not "known" during the definition, and as a result their
representation cannot be used for optimization. I think this is true
for all ocaml releases, but it is specified nowhere, and could be
wrong.
Since you're not going to write the first defintion anyway, this
shouldn't be a real problem.
The real problem is that when you use a signature like
  sig type t type r = {f:t} end
in a functor, then this signature cannot be instanciated by the
unboxed version of r when t = float. And there is no way to solve it
short of inlining functors.

Cheers,

Jacques Garrigue
-------------------
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