From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: weis
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA21641 for caml-redistribution; Tue, 11 Jan 2000 12:01:24 +0100 (MET)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA12880 for <caml-list@pauillac.inria.fr>; Tue, 11 Jan 2000 11:00:53 +0100 (MET)
Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id LAA25835
	for <caml-list@inria.fr>; Tue, 11 Jan 2000 11:00:49 +0100 (MET)
Received: from tet.kurims.kyoto-u.ac.jp (tet.kurims.kyoto-u.ac.jp [130.54.16.184])
	by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id TAA01656;
	Tue, 11 Jan 2000 19:00:42 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by tet.kurims.kyoto-u.ac.jp (8.9.3/8.9.3) with ESMTP id TAA07282;
	Tue, 11 Jan 2000 19:03:06 +0900 (JST)
	(envelope-from garrigue@kurims.kyoto-u.ac.jp)
To: mottl@miss.wu-wien.ac.at
Cc: caml-list@inria.fr
Subject: Re: ocamlyacc and polymorphic variants
Reply-To: garrigue@kurims.kyoto-u.ac.jp
In-Reply-To: Your message of "Sat, 8 Jan 2000 19:14:28 +0100 (MET)"
	<200001081814.TAA30033@miss.wu-wien.ac.at>
References: <200001081814.TAA30033@miss.wu-wien.ac.at>
X-Mailer: Mew version 1.93 on Emacs 20.4 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000111190306L.garrigue@kurims.kyoto-u.ac.jp>
Date: Tue, 11 Jan 2000 19:03:06 +0900
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
X-Dispatcher: imput version 980905(IM100)
Sender: weis

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