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=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 44172BC69; Tue, 1 May 2007 19:11:11 +0200 (CEST) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l41HB8v6014891; Tue, 1 May 2007 19:11:09 +0200 X-IronPort-AV: E=Sophos;i="4.14,475,1170595800"; d="scan'208";a="121979704" Received: from ppp8-148.lns1.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.8.148]) by ipmail01.adl2.internode.on.net with ESMTP; 02 May 2007 02:41:06 +0930 Subject: Re: [Caml-list] menhir From: skaller To: Francois.Pottier@inria.fr Cc: caml-list@inria.fr In-Reply-To: <20070501155705.GA29617@yquem.inria.fr> References: <1177756336.11923.18.camel@rosella.wigram> <20070428165058.GA31584@yquem.inria.fr> <1177821783.25394.37.camel@rosella.wigram> <20070501155705.GA29617@yquem.inria.fr> Content-Type: text/plain Date: Wed, 02 May 2007 03:11:04 +1000 Message-Id: <1178039464.8967.10.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 463774AC.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 lexbuf:01 non-terminal:01 endmarker:01 parser:01 lexbuf:01 ocamlyacc:01 sourceforge:01 arbitrary:01 wrote:01 minor:01 parsed:01 token:01 token:01 caml-list:01 On Tue, 2007-05-01 at 17:57 +0200, Francois Pottier wrote: > > 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. They're not technically spurious, but for my grammar they're spurious because the input language isn't arbitrary, it always has an ENDMARKER at the end of the token stream, and the parser never processes any symbols past that. It can't hit 'end of stream' because that's a state of the lexbuf .. and the lexbuf is is a dummy which is never updated or modifed -- so it can't ever be in the end-of-stream state. So basically, menhir is saying "what happens if you hit end of stream here? What should be done?" and the answer is "it can't happen". BTW: Ocamlyacc doesn't report any conflicts, so this is a minor incompatibility. -- John Skaller Felix, successor to C++: http://felix.sf.net