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 SAA08429; Mon, 23 Jul 2001 18:36:21 +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 SAA08416 for ; Mon, 23 Jul 2001 18:36:20 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f6NGaJL18189; Mon, 23 Jul 2001 18:36:19 +0200 (MET DST) Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) id SAA26651; Mon, 23 Jul 2001 18:36:18 +0200 Date: Mon, 23 Jul 2001 18:36:18 +0200 From: Markus Mottl To: Xavier Leroy Cc: Markus Mottl , OCAML Subject: Re: [Caml-list] illegal permutation of structure fields? Message-ID: <20010723183618.B24670@fichte.ai.univie.ac.at> References: <20010723150428.B12189@chopin.ai.univie.ac.at> <20010723172755.A5259@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010723172755.A5259@pauillac.inria.fr>; from Xavier.Leroy@inria.fr on Mon, Jul 23, 2001 at 17:27:55 +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hm, well, thanks a lot for the very elaborate explanation! ... But I am still not fully convinced (evil me! ;) On Mon, 23 Jul 2001, Xavier Leroy wrote: > That's more or less what old versions of OCaml did, but it's > incorrect. The reason is that a module signature determine the layout > of the corresponding structure: if Why doesn't the normalized inferred signature of the module determine its layout? E.g.: module A = struct let y = 1 let x = 2 end could be transformed to (tuple that describes memory layout): (2, 1) Of course, one would have to make sure that side effects are executed in the right order when the creation of the values involves any, but this should only require sorting the computations accordingly. This marginally complicates things, but ... > When you perform signature matching, the compiler recomputes the > structure representation to match the new signature. For instance: > > module C : sig val y : int val x : int end = A > > causes the compiler to generate roughly the following code > > let C = (snd A, fst A) ... such glue code wouldn't be necessary in this case anymore: the compiler could just generate: let C = A Of course, if the signature of C were more restrictive than A, we might have to generate a fresh tuple again, because some tuple slots could disappear. > so that the representation of C matches what clients of C expect from > its signature. The client would always expect the order of the normalized signature, which should make it match the order used in the implementation, which is also normalized. > If we were to allow module type equivalence up to permutation, this > strategy would be invalid. Consider: [snip] The snipped example wouldn't lead to any problems with the mentioned approach where the module implementation is already in normalized order. > However, I believe there are more complex examples involving abstract > module types (e.g. as functor parameters) where expanding module type > names would not suffice. So, let's keep it simple: no permutation! I don't see any inherent problem here, but maybe I just don't fully understand your argument. Am I missing some hidden catch? Anyway, I don't feel terribly restricted without permutation, and not having to rearrange the elements of the tuple on some simple module equations doesn't look like a big performance gain either. So even if my idea worked, I wouldn't mind if you put them on your "superfluous features"-staple... ;) Best 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