From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id DAA21183; Wed, 13 Nov 2002 03:44:55 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA21152 for ; Wed, 13 Nov 2002 03:44:54 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id gAD2iq115456 for ; Wed, 13 Nov 2002 03:44:52 +0100 (MET) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id LAA14611; Wed, 13 Nov 2002 11:41:06 +0900 (JST) To: rossberg@ps.uni-sb.de Cc: caml-list@inria.fr Subject: Re: [Caml-list] Records typing In-Reply-To: <20021113101131D.garrigue@kurims.kyoto-u.ac.jp> References: <3DCF97ED.6E81EB98@ps.uni-sb.de> <20021113101131D.garrigue@kurims.kyoto-u.ac.jp> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021113114105Z.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 13 Nov 2002 11:41:05 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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. 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