From: "Campbell, Rolf [SKY:1U32:EXCH]" <cp1v45 AT americasm01 DOT nt DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Bison and particular expressions.
Date: Mon, 28 Jun 1999 16:15:16 -0400
Organization: Nortel Networks
Lines: 55
Message-ID: <3777D7D4.BE28011B@americasm01.nt.com>
References: <01bec0e0$bcf60680$LocalHost AT thendren>
NNTP-Posting-Host: bmerhc00.ca.nortel.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.6 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Christopher Nelson wrote:

> >solve my problem with some excelent help provided by Doug Eleveld.  It had
> to
> >do with combining the "item" and the "," into one item to allow bison to
> use a
> >look-ahead token to resolve some conflicts.
>
> item can be resolved to be any number of smaller tokens.  for example, item
> could be a nonterminal that can match 'a', '*a', '**a', or '**&a'.  i find
> that using the most general definition possible, until you get to a terminal
> is usually the most efficient and easiest method to use.

    That is kind of what I do, but the original problem was:
list: parm ',' parm ','
otherlist: parm ',' parm ';'

Bison can't parse this correctly because it would require more than 1
look-ahead token.

> >I've think I got typedef's working, as well as structs and simple classes
> >(without methods) without lexical tie-ins.  Besides, scope stuff can be
> done to
> >make lexical tie-ins tricky [like]:
> >struct a {int a;};
> >
> >int j()
> >{int m,a;
> >}
>
>     This is precisely what i refered to.  That's why C also has the
> most-closely nested rule.  Your parser should maintain context information
> about what block is the current one, and the symbol table should maintain
> scope information about where the variable was declared.  If your symbol
> table knows where you are, and also knows where a variable was declared, it
> can then easily resolve the above example.  For example, compile the above
> example in gcc, and use the shadow parameter warning and you'll see what I
> mean.

    But, lexical tie-ins and scope resolution are not required for what I was
doing.  All I was oringinally trying to do was to find things that look like
function declarations.  I wasn't really conserned with validating the return
type.   In my parser:

myType myFunc(int a, char**&);

would be a valid prototype even if "myType" was not previously defined.  My
program is only designed to be run on code that cleanly compiles and thus does
not require strict validation of stuff like that.

--
     -Rolf Campbell (39)3-6318