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 RAA06649 for caml-redistribution; Tue, 11 Jan 2000 17:09:05 +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 QAA09992 for ; Tue, 11 Jan 2000 16:59:57 +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 QAA03566 for ; Tue, 11 Jan 2000 16:59:55 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id QAA30850; Tue, 11 Jan 2000 16:59:32 +0100 (MET) From: Markus Mottl Message-Id: <200001111559.QAA30850@miss.wu-wien.ac.at> Subject: Re: ocamlyacc and polymorphic variants To: garrigue@kurims.kyoto-u.ac.jp Date: Tue, 11 Jan 2000 16:59:32 +0100 (MET) Cc: caml-list@inria.fr (OCAML) In-Reply-To: <20000111190306L.garrigue@kurims.kyoto-u.ac.jp> from "Jacques Garrigue" at Jan 11, 0 07:03:06 pm 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 > 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