From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA27560; Mon, 13 May 2002 08:46:53 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA26419 for ; Mon, 13 May 2002 08:46:53 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4D6ko920589 for ; Mon, 13 May 2002 08:46:50 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id PAA13208; Mon, 13 May 2002 15:46:39 +0900 (JST) To: skaller@ozemail.com.au Cc: caml-list@inria.fr Subject: Re: [Caml-list] Bug in typing polymorphic variants found In-Reply-To: <3CDBF8AD.5070000@ozemail.com.au> References: <200205101502.RAA0000022181@beaune.inria.fr> <3CDBF8AD.5070000@ozemail.com.au> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020513154639Z.garrigue@kurims.kyoto-u.ac.jp> Date: Mon, 13 May 2002 15:46:39 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: John Max Skaller > [This is a bug report, please ignore if you are not interested, > apologies in advance ..] > The *problem* is that the type of the constructor argument > influences its run-time hash? And so the following code, > which IS executed > > | `DCL_val t -> > Hashtbl.add dfns n (id,sr,parent,`SYMDEF_dcl dcl) > ; > > is producing the *wrong* hash for the variant `SYMDEF_dcl dcl, > because the inference engine thinks the type of dcl is something > other than dcl_t. When I do a lookup of the hash table later in another > module, > I get a bad value out, since in *that* module, the correct type of the dcl > is calculated. At least, thats my guess. Well, your guess has to be wrong, because the type of a constructor arguments _does not_ influence the run-time hash of this constructor. > The complete source of my program is available from > > http://felix.sourceforge.net/felix_src.tgz > > See the web site: > > http://felix.sourceforge.net/download.html > > for information on building. > > To use the included build scripts, you must have Python installed. > After unpacking the tarball, type > > python script/maker noiscr test > > and it should build the compiler and then crash running > some of the tests. If you try the whole process again, > using Ocaml 3.01 it should work. I didn't try with 3.01, only with 3.04+10, and I get a segmentation fault on the first example. Since you use ocamlopt, I couldn't get any debugging information, so I tried again with ocamlc -g, and the error I get is a stack overflow. I expect there is a bug somewhere in your program... It is a good idea to make your makefiles to work with both ocamlc and ocamlopt, because ocamlc gives you much more debugging information. Some segmentation faults with ocamlopt give actually informative errors with ocamlc. By the way, I got errors trying to compile felix, because there was an old src/flx_parse.ml, which should not be there. > I have commented out the lines that cause Ocaml 3.01 to > give a diagnostic message. If you wish to generate the > Ocaml 3.01 errors that Ocaml 3.04 does not report, > you will need to uncomment those lines. Parts of the specification of polymorphic variants have changed since 3.01, so it is very possible than some code refused by 3.01 is now accepted. I would expect this code to be sound. > I will do everything I can to help resolve this problem, > I'd like to use new ocaml features .. and of I am already > depending on > > #variant_type > > syntax in matches, which will not be supported in Ocaml 3.05. Where did you get this idea? Of course #variant_type will stay, this is a main feature of polymorphic variants! The only change is that I would prefer people to move from the #variant_type to [< variant_type] in _types_, since the previous notation is overloaded with the one for objects in a not so nice way. But there is no reason to hurry: both syntax will still be supported in 3.05. Cheers, Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners