RE: [sv-bc] Name resolution and imports

I have been very busy and not able to comment on this discussion. 

Several objects have been raised about chaining of package imports. One
issue is pollution of the name space. I think name space pollution
created by wild card package imports is a problem with System Verilog,
but I believe package import chaining reduces name space pollution,
because it gives package developers the tools to do something about this
problem. My assumption is that most Verilog writers will be using
wildcard imports. Consider this example without package import chaining:

package mytypes;
  typedef int myint;
endpackage 

package mystuff;
  import mytypes::*;
  function myint myfunc();
       return 0;
  endfunction
endpackage


module mycode();
import mytypes::*;
import mystuff::*;
myint x;
initial x = myfunc();
endmodule

I am assuming here that most engineers will just use wildcard imports on
all packages. Because the author of the mycode module was not sure what
types he might need from the mytypes package in order to use the
functions from mystuff, he just wildcard imported all of them. If latter
on, other types are added to the mytypes package, then they will be
available for import into mycode.

On the other hand, with package chaining, mycode could be written:

module mycode();
import mystuff::*;
myint x;
initial x = myfunc();
endmodule

Now only the symbols from mytypes that are actually used in mystuff are
available for import into mycode. If someone adds another type in
mytypes that has nothing to do with mystuff, it is not available for
import into mycode.

I would also add that it is much more likely that the people writing
packages can be trained to worry about the dangers of wildcard imports
then it would be to train all engineers to worry about this. I expect
most engineers will be using wildcard imports because that is the
easiest thing to do.

Another issue about chaining is that it creates alias names, and I guess
people consider that objectionable. I don't understand this argument,
since System Verilog is already full of aliases. Typedefs and type
parameters create aliases for type names already. In fact, package
mystuff could just say:

typedef mytypes::myint myint;
 
and then it could be written without any import statement. Chaining of
package imports is no different then writing the package like this.


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Gordon Vreugdenhil
> Sent: Thursday, August 31, 2006 10:03 AM
> To: SV_BC List; SV_EC List; sv-ac@verilog.org
> Subject: [sv-bc] Name resolution and imports
> 
> All,
> 
> The name resolution working group has encountered an issue 
> that needs to be resolved at the committee level.  The issue 
> is directly addressed by Mantis 1323 -- "are imported names 
> visible to hierarchical references".  Mentor and Cadence have 
> both taken the position that they are not; Synopsys has taken 
> the position that they are.  This needs to be resolved 
> quickly as implementations have (and will continue) to 
> diverge.  This also impacts the issue of chained imports (is 
> a symbol imported into a package available for import) which 
> is also addressed by Mantis 1323.
> 
> This issue has a direct bearing on back-annotation, pli, and 
> related issues since it impacts what the system must present 
> as members of a scope and whether hierarchical names for 
> items in a design are unique or not.
> 
> Currently Mantis 1323 is listed as a BC issue.  I'd like to 
> have this issue be resolved asap due to the overall impact of 
> the interpretation differences.
> 
> Question:  should this immediately be elevated to the 
> champions level or is it appropriate to leave for SV-BC?
> 
> Independent of that decision, it would be worthwhile for 
> people to speak to this from various perspectives so that we 
> can make an informed decision.
> 
> Gord
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
>