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.