From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 65BC7BC2F for ; Sat, 27 Nov 2004 10:19:00 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iAR9J0ju021654 for ; Sat, 27 Nov 2004 10:19:00 +0100 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 KAA08724 for ; Sat, 27 Nov 2004 10:18:59 +0100 (MET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iAR9IvOE021647 for ; Sat, 27 Nov 2004 10:18:58 +0100 Received: from [192.168.1.200] (ppp217-171.lns1.syd3.internode.on.net [203.122.217.171]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iAR9It4Y061238 for ; Sat, 27 Nov 2004 19:48:56 +1030 (CST) Subject: ocamlyacc loop? From: skaller Reply-To: skaller@users.sourceforge.net To: caml-list Content-Type: text/plain Message-Id: <1101547134.9291.605.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 27 Nov 2004 20:18:55 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41A84684.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41A84681.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocamlyacc:01 sourceforge:01 unambiguous:01 ocamlyacc:01 grammar:01 stack:01 grammar:01 token:01 token:01 debugging:01 parses:01 debugging:01 tokens:01 glebe:01 ...:98 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: I have an unambiguous ocamlyacc grammar which is dying on a particular input term with a stack overflow. I'm assuming I have caused an infinite loop somehow with the grammar, but I'm not exactly sure how this can happen. Perhaps something like this: y: x { $1 } | TOKEN x: y { $1 } starting with y, input TOKEN, would loop forever. Unfortunately, debugging prints only go in executable code and show completed reductions. Any hint on how to find this problem? The actual problem is weird: x; // parses ok the x; // loops forever but I know from the debugging the 'the x' term is actually reduced correctly: with this grammar production: dollar_name: | DOLLAR qname | THE qname | qname x; // works $x; // works the x; // fails I have some trouble understanding this: the tokens THE and DOLLAR are used exactly once, in the same way as you see. Yet the parse loops forever with THE and not with $. It almost looks like there is an infinite loop in the client reduction code. I get this diagnostic output: Reducing plain old name Reducing simple parts Reducing qualified_name Reducing THE term Reducing dollar_name Reducing factor Reducing coercion which show coercion is reduced, but not application, here's more of the grammar: application: | application coercion | coercion coercion: | coercion COLON factor | suffixed_name | factor factor: | dollar_name | factor DOT ... more stuff -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net