> This different behaviour is due to a bad bug in the native code
> compilation of variants on 32-bit architectures. See PR #19 in the
> caml bug center (http://caml.inria.fr/pub/old_caml_site/bin/caml-bugs).
Ah! Ok - I am already so used to the low number of bugs in OCaml-releases
that I did not even consider this case. ;-)
But I should have been warned by the version number (2.99)...
> The order of constructor in a polymorphic variant type is irrelevant,
> because there representation does not depend on it, but only on the
> names of the constructors.
I see - so it is not possible to mess up the interpretation of the
representation by "casting" polymorphic variants to a type in which only
the order of names is changed.
> 1) Get the CVS versions of bytecomp/{matching.ml,translcore.ml}.
> 2) Just write the type as you expect it to be, and let the typechecker
> do the work. Different orders represent actually the same type, and
> should be correctly accepted.
> Still keep in mind that you may end up catching errors too late,
> making debugging more difficult. I would suggest either adding
> explicit type annotations, or combining polymorphic variants with
> monomorphic records, to enforce stricter typing from the beginning.
Thanks for the hints! I'll just wait for the next release for further
experiments.
Best regards,
Markus Mottl
-- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
This archive was generated by hypermail 2b29 : Tue Jan 11 2000 - 17:15:55 MET