From: Shalom.Bresticker@motorola.com
Date: Fri May 03 2002 - 06:39:55 PDT
Precedence: bulk
I agree. It would be confusing if "@ ( a )" is OK and "@(*)" is not.
And Peter is implicitly pointing out that it is not a big problem.
Shalom
On Thu, 2 May 2002, Peter Flake wrote:
> Date: Thu, 02 May 2002 18:39:57 +0100
> From: Peter Flake <flake@co-design.com>
> To: mac@verisity.com
> Cc: btf@boyd.com
> Subject: Re: @* and @(*) and @( * ) and (* ... *)
>
> Precedence: bulk
>
> Mac,
>
> I oppose this motion. Paul Graham and I both have parsers which will allow
> spaces and some people like to use them for clarity.
>
> Peter.
>
> At 09:33 AM 5/2/02 -0700, Michael McNamara wrote:
> >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
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
>
>
-- Shalom Bresticker Shalom.Bresticker@motorola.com Principal Staff Engineer Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
and
sponsored by Boyd Technology, Inc.