From: Peter Flake (flake@co-design.com)
Date: Thu May 02 2002 - 10:39:57 PDT
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
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
and
sponsored by Boyd Technology, Inc.