English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] illegal permutation of structure fields?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-07-26 (07:18)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] illegal permutation of structure fields?
> Then the followup question of course is: isn't it trivial to use a
> canonical layout instead, where the tuple components are sorted wrt. to
> the corresponding fields' label? This way layout is invariant wrt
> permutation in signatures. Or is there a particular problem with such a
> scheme?

It seems possible to proceed this way; I was just explaining that this
is not the way it's currently done in OCaml.

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).

> (BTW, the same holds for record and variant types, where Ocaml does not
> allow reordering of fields/constructors either.)

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...

- Xavier Leroy
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