I suspect that the precision required to specify any significant semantics within the BNF will require a complete rewrite into a formal attribute grammar. This is not a task to take up lightly. That doesn't mean there isn't value in organizing rules and choosing names to suggest the semantics. These measures tend to lead to more readable and understandable grammars. It seems like the BNF should be considered normative for the purpose of specifying syntax, but non-normative for the purpose of conveying semantics. This is what I've always assumed and, until Brad's comments, figured that everyone was assuming. Perhaps we should be explicit about this and continue to use the footnotes at the bottom of the grammar and the text of the rest of specification for semantics? -randy. Gordon Vreugdenhil wrote: > > 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-stds.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. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Oct 10 09:08:09 2007
This archive was generated by hypermail 2.1.8 : Wed Oct 10 2007 - 09:08:32 PDT