Re: ocamlyacc and polymorphic variants

From: Jacques Garrigue (garrigue@kurims.kyoto-u.ac.jp)
Date: Tue Jan 11 2000 - 11:03:06 MET

  • Next message: Markus Mottl: "Re: ocamlyacc and polymorphic variants"

    Hello,

    > I have just tried in how far it is possible to use ocamlyacc together with
    > polymorphic variants. As it seems, this is a somewhat dangerous
    > combination, because ocamlyacc-generated code requires Obj.magic internally
    > to cast values to the appropriate type.

    This should not be dangerous in itself. Polymorphic variants can be
    dangerous by there laxism, but ocamlyacc should be correct
    independently of that.

    > I am not sure in which order the data constructors are generated, i.e. what
    > internal representation the polymorphic variants get. I thought that they
    > would be generated in order of appearance, but when I implemented the
    > parser, the code behaved more than strangely, namely differently for byte-
    > and native code. This is an indication that the returned values do not
    > fully correspond to the type they are supposed to be of, possibly because
    > the internal tags of the data constructors are not in the right
    > order.

    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).

    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.

    There are also two other bugs (PR #20), common to the bytecode and
    native code version. They have little impact on user programs, but may
    be worse for ocamlyacc-generated files.

    > Is it possible at all to return polymorphic variants from the parser? If
    > yes, how do I have to specify the return type?

    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.

    Regards,

    Jacques



    This archive was generated by hypermail 2b29 : Tue Jan 11 2000 - 12:13:05 MET