RE: [sv-ec] RE: [sv-bc] name resolution question about :: names

Françoise,

Should the discussion about :: in the LRM be clarified/expanded?

-- Brad 

> I am interpreting this as a :: name is not like a hierarchical reference.
> 
> The prefix name is resolved as if it were a simple identifier, that means that the name is searched in the current scope for a declaration of the same name that is declared prior to the reference. If such a name is found, then its declaration  is bound to the prefix, the prefix name becomes the search for the next name component. If the next name is not found, that is an error and search ends.

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Francoise Martinolle
Sent: Friday, October 17, 2008 8:15 AM
To: Gordon Vreugdenhil
Cc: sv-ec@eda.org; sv-bc@eda.org
Subject: [sv-ec] RE: [sv-bc] name resolution question about :: names


 
Thanks.
I agree with your additional comments
-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Friday, October 17, 2008 10:14 AM
To: Francoise Martinolle
Cc: sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-bc] name resolution question about :: names

I agree with all of your examples.

One quick note -- in the last example, it is immaterial that
    typedef class p;
says "class".  If it were just "typedef p;" you would still get the same
result.  In either case, due to the use of "::" on the forward type, if
the actual type did not end up being a class with an appropriately typed
property "a", it would be an error.

Gord.


Francoise Martinolle wrote:
> There is a very short section in the LRM  talking about :: names which

> can be package based names, or classes based names.
>  
> It says:
> *23.7.1 Names with package or class scope resolution operator 
> prefixes*
> 
> A name with a package or class scope resolution prefix (::) shall 
> always resolve in a downwards manner
> 
> and shall never be subject to the upwards resolution rules in 23.8. 
> The package or class prefix shall be
> 
> resolved using the normal resolution rules.
> 
>  
> 
> I am interpreting this as a :: name is not like a hierarchical
reference.
> 
> The prefix name is resolved as it it were a simple identifier, that 
> means that the name
> 
> is searched in the current scope for a declaration of the same name 
> that is declared
> 
> prior to the reference. If such a name is found, then its declaration 
> is bound to the prefix, the prefix
> 
> name becomes the search for the next name component. If the next name 
> is not found, that is an error
> 
> and search ends.
> 
> Let's see if we agree on the following examples.
> 
> example 1:
> 
> package p;
> 
> int a;
> 
> endpackage
> 
> module top;
> 
> parameter p = 1;
> 
> initial p::a = 0; // error
> 
> endmodule
> 
> example 2:
> 
> package p;
> 
> int a;
> 
> endpackage
> 
> module top;
> 
> initial p::a = 0;  // this is package p, variable a
> 
> parameter p = 1;
> 
> endmodule
> 
>  
> 
> In ex (1) , p::a resolves the first name component to the parameter p 
> and an error
> 
> is reported for the second name component. In ex(2), p::a resolved to 
> the package reference to a.
> 
>  
> 
> Do we agree?
> 
> Another question regarding classes and packages.
> 
> ex(3)
> 
> package p;
> 
> int a;
> 
> endpackage
> 
> module top;
> 
> class p;
> 
> int a;
> 
> endclass
> 
> initial p::a = 1; // this is a class scope
> 
> endmodule
> 
>  
> 
> ex (4)
> 
> package p;
> 
> int a;
> 
> endpackage
> 
> module top;
> 
> initial p::a = 1; // this is a package reference to a
> 
> class p;
> 
> static int a;
> 
> endclass
> 
> endmodule
> 
> ex (4)
> 
> package p;
> 
> int a;
> 
> endpackage
> 
> module top;
> 
> typedef class p;
> 
> initial p::a = 1; // this is a class scope to a
> 
> class p;
> 
> static int a;
> 
> endclass
> 
> endmodule
> 
> 
> --
> This message has been scanned for viruses and dangerous content by 
> *MailScanner* <http://www.mailscanner.info/>, 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.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.