From: Dennis Marsa (drm@xilinx.com)
Date: Tue Jul 30 2002 - 10:40:03 PDT
Precedence: bulk
The following reply was made to PR errata/82; it has been noted by GNATS.
From: Dennis Marsa <drm@xilinx.com>
To: mac@verisity.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/82: Section 9.7.5: Description of @*, @(*) incomplete
Date: Tue, 30 Jul 2002 11:29:49 -0600
Michael McNamara wrote:
>
> drm@xilinx.com writes:
>
> > 6) Tokenization of @* and @(*). 1364-2001 does not
> > state anywhere how @* and @(*) should be tokenized.
> >
> > Is @* 1 token '@*' or 2 tokens '@' '*'?
> > Is @(*) 1 token '@(*)' or 4 tokens '@' '(' '*' ')'
> >
> > If these are to be considered multiple tokens, then
> > one must also consider how the attribute tokens
> > '(*' and '*)' interact. Thus, @(*) could also
> > be *three* tokens:
> >
> > '@' '(*' ')
> > or '@' '(' '*)'
>
> I believe that tokenization discussion this is outside the scope of
> the IEEE 1364-2001 specification. There is no discussion of
> tokenization of anything else in the specification, except perhaps the
> notes in the BNF that talk about making illegal the use of spaces
> between $ and display, or in general the use of spaces in a name.
What about Section 2 "Lexical Convensions"?
> Inany case, where we are, the standard says that @(*) must be treated
> as the implict event control; and without any special rules, this also
> allows
>
> @ ( * )
> @ (* )
> @(*)
>
> I submit that there is no ambiguity that a LALR(1) parser (like Yacc &
> bison) used in conjunction with lex (or flex) could not handle, as the
> only problem case is [Note '.' indicates where the parsers eye ball is
> focusing right now]
>
> @ (* . )
>
> versus
>
> @ (* . exp *)
>
> which the parser can disabiguate by looking ahead one token (this is
> what LALR statnds for ['L'ook'A'head 'L'eft to right scanning of
> input, constructing a 'R'ight most derivation in reverse, with
> lookahead limited to just '(1)' token]; ref Section 4.7 of Aho Sethi &
> Ulmman 'Compilers: Principles, techniques and tools, 1988), to see if
> the next token is a ')' or is part of an expression.
I agree, handling @* and @(*) as multiple tokens can be handled.
I would just like to see a statement somewhere in the standard that
says whether they are, in fact, multiple tokens, or one token.
Dennis Marsa
Xilinx, Inc.
This archive was generated by hypermail 2.1.4
: Thu Oct 10 2002 - 09:24:26 PDT
and
sponsored by Boyd Technology, Inc.