Re: [sv-bc] name resolution question about :: names

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.

That is one possible reading, but I find no support for it in section 3.13,
where the package name space is held separate from the module name space where
hierarchical references are resolved.

> 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

Disagree.  Since the name p is not bound locally to a type, it should be
sought in the package name space, where it is found to be a package.

> 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 p;
>   initial p::a = 1; // this is a class scope to a
>   class p;
>     static int a;
>   endclass
> endmodule

Agreed.

The class_scope operator syntax takes precedence over package_scope operator.
But it requires that the identifier be previously bound to a typename.
I don't know whether such a binding can be satisfied by wildcard import,
my feeling is that this could only happen after both the module and package
name spaces have failed to declare the identifier.

These opinions are not a formal committee position of my employer, but they
are currently committed behavior in some (probably all) of our products.
I personally found the "package name space" idea to be confusing at this
juncture, but not wanting to deviate from the prescriptions of section 3.13,
this was what we built.

In the world of LALR(1) parsing, the distinction is often made between
typenames and other identifiers via a context-sensitizing hack familiar
to the authors of C and C++ grammars.  Such hacks typically take the scoping
rules into account, and so leave open the possibility of binding a non-type
identifier to definitions in name spaces other than the one where type identifiers
are bound.

Greg Jaxon


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