Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: ocamlyacc and polymorphic variants
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Markus Mottl <mottl@m...>
Subject: Re: ocamlyacc and polymorphic variants
> 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