Re: ocamlyacc and polymorphic variants

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

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