Gordon, I appreciate what you're saying, but one of your assumptions is wrong: Gordon Vreugdenhil wrote: > There are relatively few names in std to worry about. But the intent of the "std" package was that it would be a home for future language extensions - so the current small size of its namespace is deceptive. Prospectively there are a large variety of useful names in "std". And the probability that they will collide with a user's package is .999999999 It is a cruel irony that the designer who writes a package so wonderful that it becomes part of std is the one whose customers' codes all break as soon as the "std" borg assimilates it. Everything else you say is correct, but having watched this exact form of language evolution happen twice before - I'm happy to finally find a way that SV can do it better. Greg > 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. >> >> >> >> > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon May 21 19:48:18 2007
This archive was generated by hypermail 2.1.8 : Mon May 21 2007 - 19:48:52 PDT