ocamlyacc and polymorphic variants

ocamlyacc and polymorphic variants

[Markus Mottl]

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.

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.

The result type enumerated the data constructors exactly in the same order
as they appeared in the parser specification, but this does not seem to
work.

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

A workaround would be to not use polymorphic variants in the parser and to
use a conversion function outside to convert the "normal" into polymorphic
ones.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: ocamlyacc and polymorphic variants

[Jacques Garrigue]

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

Re: ocamlyacc and polymorphic variants

[Markus Mottl]

> 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

Re: ocamlyacc and polymorphic variants

[Markus Mottl]

> The internal representation does only depend on the name of the
> constructor. This is described in one of Jacques Garrigues papers
> about Olabl. In particular you find, that variant tags `C00J10
> and `N60r0 have the same internal representation, so you can't
> use both of them in one program. (This was at least the case
> olabl 2.02, I haven't checked it with ocaml 2.99.)

Thanks for the explanation - now this really helps in understanding how the
internal representation looks like. I have just tried this with OCaml 2.99
- here the result:

  # `C00J10 = `N60r0;;
  In this program, variant constructors `C00J10 and `N60r0
  have same hash value.

Interesting: so the internal representation of tags for polymorphic
variants is just the hash value of their names! Luckily, the system seems
to check whether two different names accidently have the same hash value...
(though it is probably very unlikely that two hash values of "normal" names
clash).

I guess that this is always safe since all the polymorphic variants appear
in the type, which makes it always unambiguous how to interpret values.

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl