From: Paul Graham (pgraham@cadence.com)
Date: Thu May 02 2002 - 07:17:34 PDT
Precedence: bulk
Shalom,
While "@(*" cannot be the start of an attribute, only the parser knows this,
not the lexer. So when the lexer sees "(*" it assumes it is the
two-character token for beginning an attribute.
VHDL has a similar situation, where "'" can be either a single-character
token used to start an attribute (e.g., x'range) or the start of a
three-character character literal (e.g., 'a'). However, the lexer only
needs to know the preceding token type to determine what to do. If the
preceeding token is an identifier, a string, a character literal, a ")", a
"]", or the keyword "all", then "'" is the start of an attribute. Otherwise
it is the start of a character literal. This rule may sound arbitrary at
first, but in fact attributes and character literals occupy such different
areas of the syntax that there is really no ambiguity at all. It's hard to
imagine an extension to the VHDL grammar which would bring these features
into conflict.
Perhaps a Verilog lexer could do something similar, treating "(*" as two
single-character tokens if the preceding token was "@". But this is a
fragile solution. For instance, we might someday decide to add a unary
multiplication reduction operator or a pointer dereference operator "*".
Then an expression like:
y = (*x);
would have the same kind of ambiguity, which could not be solved so easily.
Or we may want to allow attributes to occur in a few more places in the
grammar, such as after the "@" token, which would break this fix.
Paul
>
> I assumed that "@ ( * )" are 4 separate tokens.
>
> I reasoned as followed:
>
> Since "@a" is legal, obviously "@" is a separate token. ("a" is an identifier.)
>
> Then if "@" and "a" are tokens, and "@(a)" is legal, then "(" and ")" are also separate tokens.
>
> So if I have "@*" or "@(*)" , then it seems that all I have done is use "*" instead of the identifier "a",
> and "*" is also a separate token.
>
> I fixed the BNF accordingly, inserting spaces between all of these.
>
> I still don't see a convincing argument to change that,
> especially since Paul points out that the "(*" cannot be an attribute.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
and
sponsored by Boyd Technology, Inc.