From: Jayaram Bhasker (jbhasker@cadence.com)
Date: Thu May 02 2002 - 09:32:23 PDT
Precedence: bulk
I agree with (second) Stu's proposal:
>> 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.
- bhasker
-----Original Message-----
From: Stuart Sutherland [mailto:stuart@sutherland-hdl.com]
Sent: Thursday, May 02, 2002 11:33 AM
To: btf@boyd.com
Subject: Re: @* and @(*) and @( * ) and (* ... *)
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.
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...
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.