We have dealt with this problem and others like it using the infamous "lex
tie-in" that is prevalent in the SNACC code. That is to say swallow the
whole thing up and deal with it on the back end essentially emulating
multi-token look aheads. It isn't pretty, but it works.
Ed Day
Principal Engineer
Objective Systems, Inc.
[EMAIL PROTECTED]
(484) 875-3020 (main)
(610) 608-4930 (mobile)
(610) 321-0361 (fax)
(877) 307-6855 (toll-free)
----- Original Message -----
From: "Patrick Henry" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 25, 2001 12:01 AM
Subject: Re: [ASN.1] asn specification
> On Thu, 18 October 2001, Olivier Dubuisson wrote:
>
> >
> > Andrew Sutton wrote:
> > >
> > > hi,
> > >
> > > i've gotten bored so i've been working on an ASN.1 compiler based on
the 97
> > > specifications. actually, it was going pretty well until i realized
that i
> > > had mistyped the SymbolsImported productions. anyway, i ran into a
problem
> > > and had some feedback or could propose an alternative syntax...
> > >
> > > it seems that the way that the SymbolsFromModuleList is constructed,
you can
> > > run into a number of shift/reduce conflicts. if AssignedIdentifier
attached
> > > to the GlobalModuleReference is a DefinedValue it conflicts with the
first
> > > Symbol in the next SymbolList for multiple imports - if the first
symbol is
> > > an abstract value (as opposed to type). if i'm just looking at this
all
> > > wrong, let me know (like if its changed in a future version).
> > >
> > > otherwise, here's an alternative syntax that i'd propose (and
implement)
> > >
> > > Exports ::=
> > > EXPORTS "(" SymbolList ")" ";" |
> > > empty
> >
> > I guess you meant "IMPORTS" here.
> >
> > > and
> > >
> > > SymbolsFromModule ::=
> > > "(" SymbolList ")" FROM GlobalModuleReference
> >
> > I don't understand what kind of problems you have with the SymbolList.
> > It seems to me that your lexer doesn't provide the right lexical items
to
> > your parser.
> >
>
> Not exactly. The problem is that the 'valuereference' lexeme is used
ambiguously in two contexts, both the SymbolList production and the
DefinedValue production (which is part of AssignedIdentifier and hence
GlobalModuleReference). There is no way to resolve the conflict in a
straight recursive descent parser without resorting to the kind of fishing
that Paul described in a prior message, q.v.
>
> As for bottom-up parsing, my compliments to Christian for his brilliant
display of LALR(1) grammar transformations; but I have serious doubts about
the sanity of such an approach.
>
> Any comments? To what extent has lex/yacc been used in ASN.1 compiler
design?
>
> Regards,
>
> Patrick Henry
>
>
> Find the best deals on the web at AltaVista Shopping!
> http://www.shopping.altavista.com
>
>
