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 TAA30159 for caml-redistribution; Sat, 8 Jan 2000 19:38:45 +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 TAA19004 for ; Sat, 8 Jan 2000 19:14:44 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id TAA14723 for ; Sat, 8 Jan 2000 19:14:42 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id TAA30033 for caml-list@inria.fr; Sat, 8 Jan 2000 19:14:28 +0100 (MET) From: Markus Mottl Message-Id: <200001081814.TAA30033@miss.wu-wien.ac.at> Subject: ocamlyacc and polymorphic variants To: caml-list@inria.fr (OCAML) Date: Sat, 8 Jan 2000 19:14:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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. 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