Mark, as I said originally, I very much welcome any rewording and/or clarification on this. The crucial thing is that the intent is agreed on. The suggestion that only a class_identifier can be used in an extension is a huge restriction to the intent and the justification on a BNF basis simply exacerbates the issue. If you are after a specific restriction, which is what Arturo is alluding to, make a specific proposal along that front. At least that will clarify what you are after. Gord. 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. >> >> -- -------------------------------------------------------------------- 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.Received on Mon Oct 8 20:51:07 2007
This archive was generated by hypermail 2.1.8 : Mon Oct 08 2007 - 20:51:31 PDT