RE: [sv-ec] RE: [sv-bc] P1800 draft2 review: Annex A

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Fri Apr 06 2007 - 12:20:11 PDT
Eric,

I don't know, because I don't know whether the intent was to allow
static class properties to be assigned to from somewhere other than from
an instance of the class.  My mental model of static class properties
has been that they are a way for objects of that class to communicate,
as with a whiteboard that all of them can see and modify.

Notice that the usage of class_scope in blocking_assignment is very
specialized -- only with a new().  It's possible that the class_scope in
that production is spurious and should be removed.

-- Brad

-----Original Message-----
From: Coffin, Eric [mailto:eric_coffin@mentor.com] 
Sent: Friday, April 06, 2007 11:34 AM
To: Brad Pierce
Cc: sv-bc@eda-stds.org; sv-ec@eda-stds.org
Subject: Re: [sv-ec] RE: [sv-bc] P1800 draft2 review: Annex A

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 12:20:35 2007

This archive was generated by hypermail 2.1.8 : Fri Apr 06 2007 - 12:20:43 PDT