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 31E39BC69 for ; Wed, 2 May 2007 20:35:59 +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 l42IZnpw017395; Wed, 2 May 2007 20:35:49 +0200 Received: by yquem.inria.fr (Postfix, from userid 18965) id A145FBC69; Wed, 2 May 2007 20:35:49 +0200 (CEST) Date: Wed, 2 May 2007 20:35:49 +0200 From: Francois Pottier To: skaller Cc: caml-list@inria.fr Subject: Re: [Caml-list] menhir Message-ID: <20070502183549.GB17473@yquem.inria.fr> Reply-To: Francois.Pottier@inria.fr References: <20070428165058.GA31584@yquem.inria.fr> <1177821783.25394.37.camel@rosella.wigram> <20070501155705.GA29617@yquem.inria.fr> <1178039464.8967.10.camel@rosella.wigram> <20070501173409.GB7308@yquem.inria.fr> <1178062950.8967.39.camel@rosella.wigram> <20070502053815.GA726@yquem.inria.fr> <1178095304.13660.71.camel@rosella.wigram> <20070502123058.GC21560@yquem.inria.fr> <1178123357.6486.49.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: <1178123357.6486.49.camel@rosella.wigram> User-Agent: Mutt/1.5.9i X-Miltered: at concorde with ID 4638DA05.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; lexbuf:01 parser:01 mutable:01 ocamlyacc:01 unambiguous:01 lalr:01 ocamlyacc:01 prec:01 vastly:01 2009:98 wrote:01 complains:01 cristal:01 caml-list:01 terminate:01 On Thu, May 03, 2007 at 02:29:17AM +1000, skaller wrote: > > Built an LR(0) automaton with 1416 states. > Built an LR(1) automaton with 2009 states. > Warning: 145 states have an end-of-stream conflict. > > Can I send you the file? Sure, please do (perhaps off the list). > Yes, but you cannot write functions that take a state argument > because lexbuf is a fixed data type and there's no where to > add in any user state data. But my point is that you never need to pass a state argument to a parser function. Instead, you can just have the function capture the address of the (mutable) state in its closure. > EOF is returned an infinite number of times in C. Point taken. > This requires the definition: parse the *shortest* head of the > input stream. In fact, if there are no end-of-stream conflicts, then the head of the input stream is *unique*, so you don't need to specify whether you are interested in a shortest or longest prefix. > > ocamlyacc never complains. It just trusts you to know what you are doing. > > I generate an .output file, grep for the word 'conflict', > and terminate my build if there is one found. I do not permit > any conflicts in my grammar: it's strictly unambiguous LALR(1). Sure, but ocamlyacc does not report end-of-stream conflicts, which I believe are real issues... > It's also pure in the sense that it doesn't use crud > like %left, %prec etc to resolve conflicts. Good, good! > [The way dypgen does this is vastly superior!] How does it work? -- François Pottier Francois.Pottier@inria.fr http://cristal.inria.fr/~fpottier/