Re: [sv-bc] wildcard package imports, std, $unit

Gordon Vreugdenhil wrote:

> Bresticker, Shalom wrote:

>> What happens if I wildcard import a package which declares a name
>> which is also declared in the std built-in package?

> At this point in SV there is no special status for std so this should
> be a conflict and work in the same manner as normal.  Hopefully a tool
> would tell you about this and you could choose to use a package prefix
> reference to resolve to what you want.

When SV vendors implement collision of wildcard import candidacy, let's
suppose they mark up the identifier's placeholder in the destination
scope in a way that makes the second (and any later) arrivals disable
the candidate (perhaps by erasing its pointer back to which package had
promised to supply the name binding).  This step is already conditional,
since it is legal to wildcard import from the same package multiple times.
Systems already inspect the existing supplier's identity, and also check
that the candidate hasn't been previously disabled.

  It wouldn't take much to check whether the candidate is supplied by
the built-in "std" package.  Candidates in that initial state could be
rendered incapable of causing a disabling collision.

The original intent in the last sentence of section 8.10.1 ...
     "This mechanism allows functional extensions to the language
      in a backward compatible manner, without the addition of new
      keywords or polluting local name spaces."
... was to provide a place to do language extension which
would have NO IMPACT on users' codes if they already defined
the proposed names for the new feature.

  Giving the "std" package a lower priority in wildcard collisions is both
feasible and in keeping with the language design intent.  To formalize this,
we could edit the last sentence of 19.2.1, which currently says:

" If the same identifier is wildcard imported into a scope from
  two different packages, the identifier shall be undefined within
  that scope, and an error results if the identifier is used."

To say:

" If the same identifier is wildcard imported into the same scope from
  several different user-defined packages, the identifier shall
  not be wildcard-importable there from any package.
  An identifier which collides with the built-in and implicitly
  wildcard imported package "std" (see section 8.10.1), can be still
  be wildcard imported from a single user-defined package; the user's
  package takes precedence and is not disabled by the collision
  with "std".
  Identifiers that cannot be wildcard imported because of an excess
  of import candidates, must be explicitly declared or imported to
  be defined in that scope."

This rewrite also corrects the impression that a wildcard collision
can prevent you from declaring the name yourself.  It removes any question
of what would happen with /three/ different packages.  I also strengthened
the wording so that the domain in which collisions happen is exactly one
scope.  Wildcard imports into differently nested scopes do not collide;
they may shadow each other in the usual way, as Gord points out below.

Establishing the lower precedence of "std" is a complication, but it's really
minor compared to the already subtle and complicated semantics of wildcard
collision resolution.

Greg Jaxon (see PS below too)

> 
>>
>> What happens if I wildcard import a package which declares a name
>> which is also declared in $unit?
> 
> $unit is "kind of sort of" like a package, however its names are
> found lexically, not via import.  So if there is a lexically closer
> import, that wins.  Example:
>    package p;
>       int x;
>    endpackage
> 
>    int x;
> 
>    module m;
>       import p::*;
>       int y = x;    // means p::x
>    endmodule
> 
> This is exactly the same reason that one would use in the following:
> 
>    module m;
>      int x;
>      task t;
>         import p::*;
>         int y = x;    // means p::x
>      endtask
>    endmodule
> 
> Gord.
> 

P.S.

In addition to being implicitly wildcard imported into $unit, I think
we need 8.10.1 to say that std is also wildcarded into every package scope.
Packages don't nest within $unit (they are their own compilation unit).

And just to raise a few hairs ;-) those std identifiers, if used by a
package declaration, will chain into clients of the package - or at least be
governed in this respect by whatever new rules are adopted for package chaining.




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