Browse thread
[Caml-list] Records typing
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | malc <malc@p...> |
| Subject: | Re: [Caml-list] Records typing |
On Wed, 13 Nov 2002, Jacques Garrigue wrote:
First of all, thanks Andrea, Jacques.
> From: Andreas Rossberg <rossberg@ps.uni-sb.de>
> > malc wrote:
> > >
> > > # module type T = sig type t type r = { f : t } end;;
> > > module type T = sig type t and r = { f : t; } end
> > >
> > > # module M : T with type t = float = struct
> > > type t = float
> > > type r = { f : t }
> > > end;;
> > >
> > > Signature mismatch: ...
> > >
> > > Is there a way to work around this?
> >
> > This seems to be a bug. You can work around it using "and" to connect
> > the type declarations in the structure:
> >
> > # module type T = sig type t type r = { f : t } end;;
> > module type T = sig type t and r = { f : t; } end
> > # module M : T with type t = float = struct
> > type t = float
> > and r = { f : t }
> > end;;
> > module M : sig type t = float and r = { f : t; } end
>
> Actually this is not a bug. And your workaround is very interesting
> (and useful).
> The fact is, the two definitions are actually semantically different
> (at least from the point of view of the compiler).
>
> % ocaml -dlambda
> Objective Caml version 3.06+16 (2002-11-04)
>
> # module M = struct type t = float and r = {f:t} end;;
> module M : sig type t = float and r = { f : t; } end
> # {M.f = 1.0};;
> [0: 1.0]
> - : M.r = {M.f = 1.}
> # module M' = struct type t = float type r = {f : t} end;;
> module M' : sig type t = float and r = { f : t; } end
> # {M'.f = 1.0};;
> [|1.0|]
> - : M'.r = {M'.f = 1.}
>
> 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.
--
mailto:malc@pulsesoft.com
-------------------
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