[Caml-list] Records typing

[malc]

# 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:
Modules do not match:
sig type t = float and r = { f : t; } end
is not included in
sig type t = float and r = { f : t; } end
Type declarations do not match:
type r = { f : t; }
is not included in
type r = { f : t; }

Is there a way to work around this?

--
mailto:ma...@pulsesoft.com

-------------------
To unsubscribe, mail caml-lis...@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

[Andreas Rossberg]

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:
> Modules do not match:
> sig type t = float and r = { f : t; } end
> is not included in
> sig type t = float and r = { f : t; } end
> Type declarations do not match:
> type r = { f : t; }
> is not included in
> type r = { f : t; }
>
> 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
#

--
Andreas Rossberg, ross...@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music."
- Kristian Wilson, Nintendo Inc.

[Jacques Garrigue]

From: Andreas Rossberg <ross...@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.

Jacques Garrigue

[Jacques Garrigue]

Follow-up to myself:

> # module M' = struct type t = float type r = {f : t} end;;
> module M' : sig type t = float and r = { f : t; } end

There is actually a bug: depending on what is the definition, it is
either in the interpretation of type declaration or in the
pretty-printer.

# module M : sig type t = float and r = { f : t; } end = M';;
Signature mismatch:
Modules do not match: [...]

That is, the signature printed is not a valid interface for the above
module. And the fix to the printer would not be easy.
But the printer is known to have a number of such bugs.

And if we were to fix instead the interpretation of type definitions,
using unboxed represention even for mutually recursive definitions,
then it would become impossible to represent the situation were a
record of float has a boxed representation, which can arise from
signature instanciation, as in the original post.

Most unfortunate.

[malc]

On Wed, 13 Nov 2002, Jacques Garrigue wrote:

First of all, thanks Andrea, Jacques.

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:ma...@pulsesoft.com

[Jacques Garrigue]

From: malc <ma...@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

[Christophe Raffalli]

>
> 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.

And when will their be inlining of functors !!!

This is really needed to benefit both from
- High level programming using modules and functors
- the necessary (I really mean necesasry) optimization for float

> Cheers,
>
> Jacques Garrigue
> -------------------
> To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.i=
nria.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

--
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christoph...@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
-------------------
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inr=
ia.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr=

[Andreas Rossberg]

Jacques Garrigue wrote:
>
> > # module M' = struct type t = float type r = {f : t} end;;
> > module M' : sig type t = float and r = { f : t; } end
>
> There is actually a bug: depending on what is the definition, it is
> either in the interpretation of type declaration or in the
> pretty-printer.

Isn't the problem already appearent on the signature level alone? The
original code snippet displayed:

> # module type T = sig type t type r = { f : t } end;;
> module type T = sig type t and r = { f : t; } end

There does not seem to be any distinction being made between recursive
and non-recursive type specs in signatures. If that really is the case,
isn't it somewhat incompatible with the treatment of type definitions,
where recursion can trigger boxing? That probably is the origin of the
following anomaly:

module X = struct type t = float type r = {f:t} end
module X1 = (X : sig type t = float type r = {f:t} end)
module X2 = (X : sig type t type r = {f:t} end with type t = float)

X1 is accepted, but X2 isn't.

Maybe I'm wrong, but I believe the whole problem can be circumvented (or
it least be simplified) by basing the decision when to unbox on a pure
syntactic criterion, rather than a semantic one. What I mean is, only
unbox when the types of the record fields are syntactically declared to
be float. A signature using an abbreviation and one using float directly
for a record field would not be compatible. That keeps out recursion
issues and is consistent with the treatment of constructor arity.

- Andreas

--
Andreas Rossberg, ross...@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
as kids, we would all be running around in darkened rooms, munching
magic pills, and listening to repetitive electronic music."
- Kristian Wilson, Nintendo Inc.