English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse 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 (14:48)
From: Andreas Rossberg <rossberg@p...>
Subject: Re: [Caml-list] Records typing
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, rossberg@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.
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