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 KAA19611; Thu, 26 Jul 2001 10:44:10 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA19601 for ; Thu, 26 Jul 2001 10:44:09 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f6Q8i8v16695; Thu, 26 Jul 2001 10:44:08 +0200 (MET DST) Received: from kastanie.ai.univie.ac.at (root@kastanie.ai.univie.ac.at [131.130.174.141]) by fichte.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA18383; Thu, 26 Jul 2001 10:44:07 +0200 Received: (from markus@localhost) by kastanie.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) id KAA05141; Thu, 26 Jul 2001 10:42:37 +0200 Date: Thu, 26 Jul 2001 10:42:37 +0200 From: Markus Mottl To: Xavier Leroy Cc: Andreas Rossberg , OCAML Subject: Re: [Caml-list] illegal permutation of structure fields? Message-ID: <20010726104237.B4973@kastanie.ai.univie.ac.at> References: <20010723150428.B12189@chopin.ai.univie.ac.at> <20010723172755.A5259@pauillac.inria.fr> <3B5C4BB0.70D3B74B@ps.uni-sb.de> <20010726091446.A17748@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: <20010726091446.A17748@pauillac.inria.fr>; from Xavier.Leroy@inria.fr on Thu, Jul 26, 2001 at 09:14:46 +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 26 Jul 2001, Xavier Leroy wrote: > In other words, I read Markus' question as "why not compare module > types after sorting their components?", and replied to that question, > but maybe he meant "why not determine the memory layout of structures > after sorting their components?". In the latter case, the answer is > that it could probably be done, but I see no real strong need for this > (see below). Yes, that's what I meant. Maybe my question was ill-formulated: in my first mail I only mentioned signatures and implicitly assumed that the order of memory layout would follow. > Yes, but would this be really useful? Manifest type declarations > and manifest module types in signatures must be implemented by > the same type/module type declaration in the matching structure. > This is generally done by generous cut&paste between the signature > and the structure. What would we gain by allowing reordering fields, > constructors or module type components? Except making it harder for > the programmer to spot mismatches between the two declarations... I mostly agree on this (what concerns variants and records). I still think that module types are a bit different, because their purpose is to abstract, whereas variants and records are concrete representations. I don't think anybody would be hurt by a more relaxed handling of "law and order": you can still use cut&paste then, and there is less of a chance that people run into mile long compiler output due to conflicting signature definitions. The latter is surely much more difficult to deal with than comparing two sum type definitions for equality. Anyway, I don't feel particulary annoyed by the current way things are handled. It has taken quite a while before I even noticed this kind of behaviour... 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