>From: Greg Jaxon <Greg.Jaxon@synopsys.com> >That is one possible reading, but I find no support for it in section 3.13, >where the package name space is held separate from the module name space where >hierarchical references are resolved. Specifying that package names are in a separate name space appears to be done for a couple of reasons. It is part of specifying that the same name cannot be used for different packages, even in different compilation units. And it means that package names and module/interface/program names are in different name spaces, so they can overlap. This is reasonable since only an instantiation can be resolved to a module/interface/program name. This requires special treatment of module/interface/program names, which already exists. >> If such a name is found, then its declaration is bound to the prefix, >> the prefix name becomes the search for the next name component. >> If the next name is not found, that is an error and search ends. >Disagree. Since the name p is not bound locally to a type, it should be >sought in the package name space, where it is found to be a package. The LRM states "The package or class prefix shall be resolved using the normal resolution rules." Can you point to a description of the normal resolution rules that involves checking whether a name is bound locally to a type? The normal resolution rules I am familiar with will stop when the name is found. >The class_scope operator syntax takes precedence over package_scope operator. Again, can you point to a specification of this in the LRM? Note that there is a problem with trying to specify different rules for resolving the name when it is a class scope versus a package scope. We don't know which it is until after it is resolved. Such a paradox could be avoided by trying to resolve as a class first, and then as a package if that fails, which seems to be what you are suggesting. Actually, you seem to be saying to resolve it as a type first, and then a package. That helps in the situation where the name is a type parameter or forward declaration, so you don't know whether it is a class early on. I think this rule could be made to work, but I don't see it in the LRM. The LRM just says to use the normal resolution rules. It does not say to use the normal resolution rules but only look at types and package names and ignore the name in any other context. >I personally found the "package name space" idea to be confusing at this >juncture, but not wanting to deviate from the prescriptions of section 3.13, >this was what we built. The whole "name space" section is a mess, and corresponds poorly to the real situations in the language. As I said earlier, the separate name space for packages seems to be there to specify that the names can overlap modules, but cannot overlap other packages. There seem to be some problems with trying to regard it as a completely separate name space however. What happens if you declare a package p with a variable v, and declare a class p with a member v in the $unit scope? What does p::v refer to? If package names are in a separate name space, then this is presumably legal. They appear to be at the same scope "level", just outside the module. I don't know whether we have rules that tell us whether to search $unit or the package name space first. More generally, I don't know whether the "normal" search order has been fully specified. There may still be a lot of things that people are just assuming, and different people may be assuming differently. When I read that these prefixes are resolved normally, I expect that it will resolve to the same declaration that it would if the name were a reference to a variable. But we know that it can (should) resolve to a package. That implies that normal resolution will look in the package name space at some point. But that implies that resolution of names in other contexts will look in the package name space, even if they are clearly not packages. That seems more surprising. Suppose I have a call to a function that is not declared locally or in $unit. I would expect it to eventually be resolved hierarchically. I would be surprised if I got an error because it resolved to a package with the same name, and you cannot call a package as a function. But if normal resolution looks at package names, then that is presumably what would happen. If normal name resolution does not take into account whether a name was used as the prefix of a clas resolution operator, then that goes both ways. >In the world of LALR(1) parsing, the distinction is often made between >typenames and other identifiers via a context-sensitizing hack familiar >to the authors of C and C++ grammars. Such hacks typically take the scoping >rules into account, and so leave open the possibility of binding a non-type >identifier to definitions in name spaces other than the one where type identifiers >are bound. Yes, I agree that special rules could be applied here. The question is whether the LRM specifies such rules. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Oct 17 10:38:17 2008
This archive was generated by hypermail 2.1.8 : Fri Oct 17 2008 - 10:40:32 PDT