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

Greg,

I disagree with your proposed solution.

SV already allows explicit disambiguation in the presence
of conflicts -- use explicit import.

There are relatively few names in std to worry about.  If
someone really wants:
    module top;
       import p::*;
       mailbox m;
    endmodule
to mean something other than std::mailbox, I don't feel
at all bad about requiring the user to have:
    module top;
       import p::mailbox;
       import p::*;  // if you need other stuff
       mailbox m;
    endmodule

That is clearly legal, is already compliant, and makes it
clear from a usability standpoint that the resolution
of the name "mailbox" was *intended* to be different than
the std::mailbox.

Gord.


Greg Jaxon wrote:
> 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.
> 
> 
> 
> 

-- 
--------------------------------------------------------------------
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.