Home     About     Download     Resources     Contact us

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at ocaml.org.

Browse thread
[Caml-list] Records typing
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: 2002-11-13 (09:58) From: malc 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

```