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 740C9BC69 for ; Tue, 1 May 2007 17:57:15 +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 l41Fv5SV021045; Tue, 1 May 2007 17:57:06 +0200 Received: by yquem.inria.fr (Postfix, from userid 18965) id D46BEBC69; Tue, 1 May 2007 17:57:05 +0200 (CEST) Date: Tue, 1 May 2007 17:57:05 +0200 From: Francois Pottier To: skaller Cc: caml-list@inria.fr Subject: Re: [Caml-list] menhir Message-ID: <20070501155705.GA29617@yquem.inria.fr> Reply-To: Francois.Pottier@inria.fr References: <1177756336.11923.18.camel@rosella.wigram> <20070428165058.GA31584@yquem.inria.fr> <1177821783.25394.37.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: <1177821783.25394.37.camel@rosella.wigram> User-Agent: Mutt/1.5.9i X-Miltered: at concorde with ID 46376351.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocamlyacc:01 parser:01 parsers:01 recursion:01 recursive:01 lexbuf:01 non-terminal:01 wrote:01 parsed:01 token:01 rec:01 cristal:01 caml-list:01 functions:01 pottier:01 Hello, On Sun, Apr 29, 2007 at 02:43:03PM +1000, skaller wrote: > > An option to generate tables like ocamlyacc would clearly be useful. > > Although that defeats one of the future advantages of Menhir: > embedding. To understand what I mean you might look at the Felix > parser generator. In Felix you can write parsers in any scope, > and the user actions bind to the containing scope. I don't see why there is a relationship between the style of code generation (code versus tables) and embedding. Embedding in Menhir is supported indirectly via %parameter directives. > It is possible (but I'm no expert!!) that the non-linearity > in compiling Menhir generated code is due to a very > large let rec/and/... being generated. Some extra analysis > might fix that, i.e. using recursion only when necessary, > and let/and/in otherwise (though I have no idea how to > do that). I have tried that, but it does not help. Most (say, 95%) of the functions generated by Menhir are truly mutually recursive. > So the conflicts are spurious: end of stream can't be parsed > (but of course Menhir doesn't know that). This is good, > because Mehir CANNOT detect end of stream, since my lexbuf > is a dummy and is not used at all. Perhaps the terminology "end-of-stream conflict" is badly chosen. These conflicts are not just about detecting the end of the stream: they are about recognizing a non-terminal symbol without overshooting, that is, without unnecessarily requesting a lookahead token (a request which, if the end of stream has been reached, could be unsatisfiable, or could be blocking). These conflicts are not "spurious": just like shift/reduce or reduce/reduce conflicts, they will cause trouble. -- François Pottier Francois.Pottier@inria.fr http://cristal.inria.fr/~fpottier/