From: Michael McNamara (mac@verisity.com)
Date: Thu May 02 2002 - 09:33:13 PDT
Precedence: bulk
Stuart Sutherland writes:
> Precedence: bulk
>
> All,
>
> It seems to me that many of these issues could be resolved if the 1364
> committee published an official errata that as a minimum made white spaces
> in @(*) illegal, e.g. @( * ). I do not believe there are any examples of
> having white spaces in any of the text of the LRM, so publishing this
> errata would not violate any thing. It would be a textual clarification to
> the BNF--something that is done a lot already.
>
> The errata could also state that @* area @(*) are single tokens, which I
> understood was the intent.
>
> Personally, I think @(*) should be made illegal as well. It is not needed,
> and as this thread has shown, is difficult to implement. Making that
> change may be more than can be done as an errata--I don't know if there are
> any IEEE guidelines on what is or is not errata.
Do I have a second for the motion?
>
> The other choice would be to change the attribute funny braces to something
> different.
>
> In either case, it was not the intent of the 1364 standards group to
> introduce new ambiguity into the language. IMHO, this issue really is an
> errata, and should be officially dealt with by the standards group
> ASAP.
>
> Mac, you are now the boss...
I will investigate the IEEE errata procedures.
-mac
>
> Stu
>
> At 07:17 AM 5/2/2002, Paul Graham wrote:
> >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.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland Sutherland HDL Inc.
> stuart@sutherland-hdl.com 22805 SW 92nd Place
> phone: 503-692-0898 Tualatin, OR 97062
> www.sutherland-hdl.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
and
sponsored by Boyd Technology, Inc.