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 PAA01964; Mon, 23 Jul 2001 15:04:31 +0200 (MET DST) 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 PAA02106 for ; Mon, 23 Jul 2001 15:04:30 +0200 (MET DST) Received: from chopin.ai.univie.ac.at (chopin.ai.univie.ac.at [131.130.174.170]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f6ND4TL14671 for ; Mon, 23 Jul 2001 15:04:29 +0200 (MET DST) Received: (from markus@localhost) by chopin.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) id PAA13276 for caml-list@inria.fr; Mon, 23 Jul 2001 15:04:28 +0200 Date: Mon, 23 Jul 2001 15:04:28 +0200 From: Markus Mottl To: OCAML Subject: [Caml-list] illegal permutation of structure fields? Message-ID: <20010723150428.B12189@chopin.ai.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hello, I've just found out to my surprise that the following does not work: file: bla.ml --------------------------------------------------------------------------- module type FOO = sig val x : int val y : int end --------------------------------------------------------------------------- file: bla.mli --------------------------------------------------------------------------- module type FOO = sig val y : int val x : int end --------------------------------------------------------------------------- This yields the following error: The implementation bla.ml does not match the interface bla.cmi: Module type declarations do not match: module type FOO = sig val x : int val y : int end is not included in module type FOO = sig val y : int val x : int end Illegal permutation of structure fields Why is this illegal? Wouldn't it be very straightforward to normalize the signatures (e.g. sort elements by name) before matching them? I knew that there is a somewhat similar restriction for record types, which does not allow permutation of record elements in the type definitions of implementation and interface. In the latter case I see that without normalization there would be problems correctly accessing record elements, but I don't quite understand the rationale behind the first restriction. Wouldn't normalization get rid of the problems in both cases? Or am I overlooking anything? Regards, Markus Mottl -- Markus Mottl markus@oefai.at Austrian Research Institute for Artificial Intelligence http://www.oefai.at/~markus ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr