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

I filed these suggestions as Mantis 1820.

Shalom

> -----Original Message-----
> From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
> Sent: Thursday, May 17, 2007 8:32 PM
> To: Gordon Vreugdenhil
> Cc: Bresticker, Shalom; sv-bc@eda.org
> Subject: 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.