I'm sorry for not responding. I have been recovering from a very bad cold. On class extension from type parameters: There is no text in the LRM to suggest this is legal. There are no examples of this in the LRM. The whole argument that this is allowed is based on an expansive interpretation of the BNF. Allowing this raises many other issues, that Gord is now raising. None of these issues are addressed in the LRM. I think these issues were not addressed because it did not even occur to most people that the LRM could be interpreted to allow this. On type parameters used with the :: operator. There has been very little discussion of this. The LRM is much clearer here. Section 8.22 says: The left operand of the scope resolution operator :: shall be a class name, package name (see 25.2), covergroup type name, coverpoint name or cross name. Another section of the LRM allows $unit. There is absolutely no reason to believe that the LRM currently allows type parameters to be the left operand of a scope resolution operator. Both of these are reasonable extensions, but they also raise new issues. I am opposed to 2087. I think this language creates more confusion. If we want to allow type parameters to extend classes and be used with the scope resolution operator, then we should add clear simple language to that effect. I am not opposed to doing this in principal. Given the current schedule or the proposed one month extension, I can not see where we have the time to resolve all the issues that these enhancements raise. Given the current schedule and proposed extension, I think all we can do to clarify the LRM is add text that forbids type parameters to be used to extend classes or with the scope resolution operator. If we want to consider these enhancements, I think it will require 3 or 4 months to understand and consider all the issues raised. > -----Original Message----- > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On > Behalf Of Gordon Vreugdenhil > Sent: Wednesday, October 10, 2007 7:26 AM > To: Bresticker, Shalom > Cc: Brad Pierce; sv-ec@eda.org > Subject: Re: [sv-ec] Re: Type parameters, typedefs, and > general BNF semantics > > > Right. I think that there is still much of that intent > present -- the BNF by itself does not *define* the semantics. > That was Randy's point as well -- reading the BNF semantics > hints too tightly (as Mark did) introduces all sorts of > issues that we should not try to address in the BNF. > > Given Mark's position, I definitely would like some variant > of this statement explicitly back in. 2087 proposes > something with the same basic intent but doesn't mention the > "italicized part" since the identifer qualifiers are no > longer italicized (we just have productions from identifier > for everyhing). I want to preclude any future serious > misunderstanding on this since the ramifications to the > overall language are very significant when such > interpretations are made. > > I certainly do not want to start expanding the grammar in an > attempt to provide more definite semantics. > > > Brad or Shalom, without going back an re-introducing all of > the "italicized" parts, can you come up with some better > language that I've used in 2087 to express this? > > Gord. > > > > > Bresticker, Shalom wrote: > > This is similar to what used to be in the LRM in 1.4: > > > > If the name of any category starts with an italicized part, it is > > equivalent to the category name without the italicized part. The > > italicized part is intended to convey some semantic > information. For > > example, "msb_index" and "lsb_index" are equivalent to "index." > > > > Shalom > > > > > -------------------------------------------------------------- > ---------- > > *From:* owner-sv-ec@server.eda.org > > [mailto:owner-sv-ec@server.eda.org] *On Behalf Of *Brad Pierce > > *Sent:* Wednesday, October 10, 2007 2:04 AM > > *To:* sv-ec@server.eda.org > > *Subject:* RE: [sv-ec] Re: Type parameters, typedefs, > and general > > BNF semantics > > > > The semantic prefixes are intended to be normative, as > discussed > > in > > > > > > > <http://www.eda-stds.org/sv-ac/hm/2599.html>_http://www.eda-st > ds.org/sv-ac/hm/2599.html_ > > _ _ > > ___ _ > > _ _ > > _If that's not clear enough in the LRM, it should be clarified._ > > _ _ > > ___ _ > > _ _ > > _-- Brad_ > > _ _ > > ___ _ > > _ > > _ > > _ _ > > > -------------------------------------------------------------- > ---------- > > _ *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On > > Behalf Of *Randy Misustin > > *Sent:* Tuesday, October 09, 2007 10:23 AM > > *To:* Mark Hartoog > > *Cc:* Vreugdenhil, Gordon; SV_EC List; Mehdi Mohtashemi > > *Subject:* Re: [sv-ec] Re: Type parameters, typedefs, > and general > > BNF semantics > > > > _ > > _ _ > > _Mark Hartoog wrote: _ > >> _ _ > >> > >> _There already is a BNF rule, type_identifier, that > specifies where > >> type parameters and typedefs can be used. _ > >> > > _Hello all, > > > > Aren't we straying pretty far from reality here? The > BNF describes > > the grammar in terms of what lexical tokens constitute valid > > sentences in SystemVerilog's syntax. As such, both > > *class_identifier* and *type_identifier* derive the > same rule (not > > surprisingly, named simply *identifier*) in section A.9.3. > > Syntactially, *class_identifier* and *type_identifier* are > > interchangeable. > > > > The distinctions being discussed here are semantic in nature and > > derive from the normative text, not the BNF. It seems to me that > > either interpretation is /syntactically /legal, according to the > > BNF. The discussion should be what interpretation is > /semantically > > /legal, and if ambiguous or inconsistent, what's the > appropriate remedy. > > > > -randy. > > > > Mark Hartoog wrote: _ > >> _ _ > >> > >> _I think this kind of catch all language in the LRM is > a very bad > >> idea. > >> There already is a BNF rule, type_identifier, that > specifies where > >> type parameters and typedefs can be used. If there are > places where it > >> needs to be added, then we should consider those > proposals. This > >> proposal > >> is so vague that no one can understand what they might > be enabling by > >> approving this. You want to allow typedefs and type parameters > >> anywhere > >> "unless otherwise restricted". What exactly does that > phase mean. > >> > >> Consider a class declaration: > >> > >> class_declaration ::= // from A.1.2 > >> [ virtual ] class [ lifetime ] class_identifier [ > >> parameter_port_list ] > >> [ extends class_type [ ( list_of_arguments ) ] ]; > >> { class_item } > >> endclass [ : class_identifier] > >> > >> Surely you are not suggesting that the declaration name of the > >> class can > >> be a typedef or type parameter. Where is the > restriction for this? > >> Is it > >> just > >> that it makes no sense? > >> > >> I think this change would only further confuse the issue. > >> > >> > -----Original Message----- > >> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On > >> > Behalf Of Gordon Vreugdenhil > >> > Sent: Monday, October 08, 2007 3:13 PM > >> > To: SV_EC List; Mehdi Mohtashemi > >> > Subject: [sv-ec] Re: Type parameters, typedefs, and general > >> > BNF semantics > >> > > >> > > >> > > >> > Gordon Vreugdenhil wrote: > >> > [...] > >> > > I'll follow-up to this a bit later today with a > Mantis item and > >> > > proposal to address what I think is the more consistent and > >> correct > >> > > way in which to read the intent of the LRM in this area. > >> > > >> > > >> > I have filed Mantis 2087 on this issue and attached > a proposal. > >> > > >> > Mehdi, given the potential for substantial impact on the > >> > overall LRM if this proposal does not express the intent of > >> > the committee, could we address this at the next EC meeting? > >> > > >> > Gord. > >> > -- > >> > > -------------------------------------------------------------------- > >> > Gordon Vreugdenhil > 503-685-0808 > >> > Model Technology (Mentor Graphics) > gordonv@model.com > >> > > >> > > >> > -- > >> > This message has been scanned for viruses and > >> > dangerous content by MailScanner, and is > >> > believed to be clean. > >> > > >> > > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > >> > >> > >> _ > >> > > _ > > -- > > This message has been scanned for viruses and > > dangerous content by *MailScanner* > <http://www.mailscanner.info/>*, > > and is > > believed to be clean. > > -- > > This message has been scanned for viruses and > > dangerous content by > <http://www.mailscanner.info/>**MailScanner* > > <http://www.mailscanner.info/>*, and is > > believed to be clean. *_ > > > > > --------------------------------------------------------------------- > > Intel Israel (74) Limited > > > > This e-mail and any attachments may contain confidential > material for > > the sole use of the intended recipient(s). Any review or > distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > > > > -- > > This message has been scanned for viruses and dangerous content by > > *MailScanner* <http://www.mailscanner.info/>, and is believed to be > > clean. > > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun Oct 14 16:46:09 2007
This archive was generated by hypermail 2.1.8 : Sun Oct 14 2007 - 16:46:31 PDT