You're right Brad, I made a mistake in overlooking the class_type production. Brad do you agree then that the portion in question of the right-hand side of the rule for variable_value should simply be the following? [ implicit_class_handle . | class_scope | package_scope ] -Eric Brad Pierce wrote: > But class_scope already begins with a [package_scope] and ends with a > {}-repetition. > > class_scope ::= class_type :: > > class_type ::= > ps_class_identifier [ parameter_value_assignment ] > { :: class_identifier [ parameter_value_assignment ] } > > ps_class_identifier ::= [ package_scope ] class_identifier > > > -- Brad > > -----Original Message----- > From: Coffin, Eric [mailto:eric_coffin@mentor.com] > Sent: Friday, April 06, 2007 11:08 AM > To: Bresticker, Shalom > Cc: Brad Pierce; sv-bc@eda-stds.org; sv-ec@eda-stds.org > Subject: Re: [sv-ec] RE: [sv-bc] P1800 draft2 review: Annex A > > Hi, > > The grammar ' [ implicit_class_handle . | class_scope | package_scope > ]' isn't quite right either. In many places in Annex A where a rule > specifies 'class_scope | package_scope' I think we should replace this > text with a new rule which I'll call 'package_class_scope'. This new > rule would be defined as: > > package_class_scope ::= [ package_scope ] { class_scope } > > The rule 'variable_lvalue' becomes: > > variable_lvalue ::= > [ implicit_class_handle . | package_class_scope ] > hierarchical_variable_identifier select > | { variable_lvalue { , variable_lvalue } } > | [ assignment_pattern_expression_type ] > assignment_pattern_variable_lvalue > | streaming_concatenation > > If IEEE 1800-2008 allows nested classes declarations we can have > something like this: > > package P; > class C; > class D; > typedef enum { red, yellow, green } E; > endclass > endclass > endpackage > > module A; > import P::*; > initial $display("Value is: %d", > P::C::D::E'(red) // Interesting package > & class scoping > ); > endmodule > > > Or maybe even this: > > package P2; > class C2; > typedef enum { red, yellow, green } E2; > class D2; > typedef enum { cyan, magenta, blue } E2; > // reference to "C2::E2'(green)" here... > endclass > endclass > endpackage > > > In general the LRM needs to allow zero or one package scopes followed by > zero or more class scopes. > > Other rules which need alteration include: A.2.2.1 'data_type', A.6.2 > 'blocking_assignment', A.8.4 'constant_primary', A.8.4 'primary'. > > Rule 'ps_class_identifier' should be changed to: > > ps_class_identifier ::= [ package_class_scope ] class_identifier > > -Eric > > > > Bresticker, Shalom wrote: > >> Mantis 1771 >> >> >> >>> -----Original Message----- >>> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] >>> On Behalf Of Brad Pierce >>> Sent: Friday, April 06, 2007 7:39 AM >>> To: sv-bc@server.eda-stds.org >>> Cc: sv-ec@server.eda-stds.org >>> Subject: [sv-ec] RE: [sv-bc] P1800 draft2 review: Annex A >>> >>> >>> >>>> Looking at this, I noted that blocking_assignment in A.6.2 and >>>> >>>> >>> primary >>> in A.8.4 have >>> >>> >>>> [ implicit_class_handle . | class_scope | package_scope ] >>>> >>>> instead of >>>> >>>> [ implicit_class_handle . | package_scope ]. >>>> >>>> Is the omission of class_scope correct here? >>>> >>>> >>> Good question. See also -- >>> >>> http://www.eda-stds.org/sv-ec/hm/3701.html >>> http://www.eda-stds.org/sv-ec/hm/3795.html >>> >>> -- Brad >>> >>> [ Replying to http://www.eda-stds.org/sv-bc/hm/5781.html .] >>> >>> -----Original Message----- >>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of >>> Bresticker, Shalom >>> Sent: Thursday, April 05, 2007 8:29 PM >>> To: Coffin, Eric; sv-bc@eda-stds.org >>> Subject: RE: [sv-bc] P1800 draft2 review: Annex A >>> >>> Hi, >>> >>> >>> >>>> * Page 941. Change the title from "Formal syntax (1800-2005 Annex >>>> >>>> >>> A)" >>> >>> >>>> to >>>> "Formal syntax (1800-2008 Annex A)". >>>> >>>> >>> [SB] The text in parentheses is noting the source of the text. The >>> source is Annex A of 1800-2005, so it is correct. >>> >>> >>> >>> >>>> * Page 975. Change the first right hand side of the rule >>>> 'variable_lvalue' in A.8.5 from: >>>> >>>> [ implicit_class_handle . [ package_scope ] >>>> hierarchical_variable_identifier select >>>> >>>> to: >>>> >>>> [ implicit_class_handle . | package_scope ] >>>> hierarchical_variable_identifier select >>>> >>>> This is just a change of '[' to '|' in the second l-bracket. >>>> >>>> >>> [SB] You are correct. Stu incorrectly changed it as part of Mantis >>> 1495 >>> and SV-AC already spotted this. >>> >>> Looking at this, I noted that >>> blocking_assignment in A.6.2 and primary in A.8.4 have >>> >>> [ implicit_class_handle . | class_scope | package_scope ] >>> >>> instead of >>> >>> [ implicit_class_handle . | package_scope ]. >>> >>> Is the omission of class_scope correct here? >>> >>> Thanks, >>> Shalom >>> >>> -- >>> 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, and is believed to be clean.Received on Fri Apr 6 11:34:40 2007
This archive was generated by hypermail 2.1.8 : Fri Apr 06 2007 - 11:34:47 PDT