From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <skaller@users.sourceforge.net>
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78])
	by yquem.inria.fr (Postfix) with ESMTP id 2C6A3BB9C
	for <caml-list@yquem.inria.fr>; Sun,  4 Dec 2005 17:48:00 +0100 (CET)
Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203])
	by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jB4GlwRd003125
	for <caml-list@yquem.inria.fr>; Sun, 4 Dec 2005 17:47:59 +0100
Received: from rosella (ppp33-4.lns1.syd2.internode.on.net [59.167.33.4] (may be forged))
	by smtp3.adl2.internode.on.net (8.12.9/8.12.6) with ESMTP id jB4GkMbF075088;
	Mon, 5 Dec 2005 03:16:23 +1030 (CST)
	(envelope-from skaller@users.sourceforge.net)
Subject: Re: [Caml-list] yacc question
From: skaller <skaller@users.sourceforge.net>
To: "Robert W." <slrn_robert@yahoo.de>
Cc: caml-list@yquem.inria.fr
In-Reply-To: <20051204150339.GA10618@waltraud.manson.mm>
References: <1133705740.11050.14.camel@rosella>
	 <20051204150339.GA10618@waltraud.manson.mm>
Content-Type: text/plain
Date: Mon, 05 Dec 2005 03:46:22 +1100
Message-Id: <1133714782.11050.42.camel@rosella>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-Miltered: at nez-perce with ID 43931DBE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)!
X-Spam: no; 0.00; caml-list:01 ocamlyacc:01 parses:01 lexer:01 token:01 specifies:01 expr:01 expr:01 token:01 trailing:01 buffer:01 parser:01 grammar:01 recursive:01 ocamlyacc:01 
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled 
	version=3.0.3

On Sun, 2005-12-04 at 16:03 +0100, Robert W. wrote:

> ocamlyacc parses longest match by default.
> Your rule for atoms seem to complex or you lexer isn't able to extract
> the token for atoms correctly from the line.

When I parse atoms only, it all works fine. The problem
is that if the user specifies a production like:

#statement select expr within statement ;

then if I parse 'expr' with 'atom' this will not be allowed:

select 1 + 2 within print x;

because '1 + 2' isn't an atom. The user would be forced to write:

select (1 + 2) within print x;

But if I parse with 'expr' instead of atom,
the parse fails when it hits the unknown symbol 'within'.

> >   | expr token_not_allowed_in_expressions
> > 
> > and then 'put back' the trailing token into the buffer.
> > Is there another way?
> > 
> This shouldn't be necessary, normally you can redesign your parser
> rules to avoid this.

The problem is I'm trying to add 'on the fly' user 
defined grammar productions -- so the 'grammar' is 
extensible. This will be done by recursive descent,
but hooked inside, and hooking, the existing ocamlyacc
grammar.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net