Re: ocamlyacc and polymorphic variants

From: Markus Mottl (mottl@miss.wu-wien.ac.at)
Date: Tue Jan 11 2000 - 17:09:05 MET

  • Next message: Markus Mottl: "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/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