From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id CB328BC6B for ; Sat, 28 Apr 2007 18:51:13 +0200 (CEST) Received: from yquem.inria.fr (yquem.inria.fr [128.93.8.37]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l3SGp1c6029135; Sat, 28 Apr 2007 18:51:01 +0200 Received: by yquem.inria.fr (Postfix, from userid 18965) id 55A2DBC6B; Sat, 28 Apr 2007 18:50:58 +0200 (CEST) Date: Sat, 28 Apr 2007 18:50:58 +0200 From: Francois Pottier To: skaller Cc: caml-list@inria.fr Subject: Re: [Caml-list] menhir Message-ID: <20070428165058.GA31584@yquem.inria.fr> Reply-To: Francois.Pottier@inria.fr References: <1177756336.11923.18.camel@rosella.wigram> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1177756336.11923.18.camel@rosella.wigram> User-Agent: Mutt/1.5.9i X-Miltered: at concorde with ID 46337B75.005 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; tokens:01 ocamlopt:01 bug:01 ocamlopt:01 yup:01 ocamlyacc:01 ocamlyacc:01 semantics:01 28,:98 4.5:98 meg:98 wrote:01 token:01 token:01 cristal:01 Hello, On Sat, Apr 28, 2007 at 08:32:16PM +1000, skaller wrote: > Second, I got a "rather a lot" of states have end-of-stream conflicts. > What's that about? That's precisely about "overshooting" the end of the token stream (reading one too many tokens). The issue is described in the manual. > Third the generated ml file was 4.5 Meg. Ocamlopt on amd64 hung for so long > I almost posted a bug report for Ocamlopt, but finally it finished. Yup, I am somewhat disappointed that ocamlopt does not seem to have linear time complexity, but I shouldn't complain too loud, my boss may be listening :) An option to generate tables like ocamlyacc would clearly be useful. > Basically: when Ocamlyacc reduces a production, it sometimes > ends on the last token, and sometimes it overshoots by 1. I don't know the details of your grammar, but our (perhaps naive) view is that you should modify your grammar to avoid end-of-stream conflicts (and Menhir's conflict reports will help you do that). Then, Menhir will not overshoot. > The semantics used are: when the exprx is processed the > action arranges to push the terminator token back > into the token stream. How is this done? It is possible that this hack is not compatible with Menhir, because Menhir keeps a local cache of the next token, which is not properly updated when you push your old token back. -- François Pottier Francois.Pottier@inria.fr http://cristal.inria.fr/~fpottier/