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

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

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