Re: [Caml-list] illegal permutation of structure fields?

[Markus Mottl <markus@mail4.ai.univie.ac.at>]

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