Re: ocamlyacc and polymorphic variants

[Markus Mottl <mottl@miss.wu-wien.ac.at>]

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