Re: [sv-ec] Re: [sv-bc] name resolution question about :: names

Steven,

   Thanks for exploring the issue further.  Since the "normal"
name resolution rules (elaborate though they are) never reach the
package name space, I blew right past that LRM hand-waving.

   In the Bison-based LALR(1)-ish parser I work on, the tokenization of
typenames vs ordinary identifiers is settled very early (actually before
name resolution proper).  Any expressive loss due to this design choice
seems minor compared to the clarity it brings to the rest of the grammar
description.

   Under this system, it is possible to direct the name resolution
of class_scope references down the "normal" resolution paths, and
the package_scope references can go directly to package name space,
ignoring local bindings altogether.  Having the name token arrive under
distinctive categories (typename vs other(s)) makes this an easy
choice.  I agree that none of this is in the LRM.  It's just what
exists out in the workaday world of language processing.  Not ideal,
but certainly not exotic nor impractical.

   The one choice I think it leaves is when a typename is found to be
bound to non-class type.  [Here I'd like to add that enum types still
seem ripe for scope operator.]  In such cases (say "p::" where "p" is
a struct identifier), there is a temptation to fail over to package
name space.  We resisted doing this because, as you observed, "normal"
resolution rules (i.e. what got you to the type definition in the first
place) never visit the package name space.

  So while I respect the Normal Resolution clause in the LRM, we
did not feel it applied to the package_scope operator.  At the time,
the (draft) grammar was also arranged in a way that gave more emphasis
to the different pedigrees of the two "scope operator" definitions.
I regarded the hand-waving text as just being an inadequate merger of
the two specs, not as the definitive specification of both.

  In summary, we have a minor diff.  My reading is a proper
extension of Françoise's even considering the wildcard triggering
rules:
   If the "normal" rule for handling wildcard candidates applies to
   package names, Françoise would say that e.g., a wildcard function
   named "p" might be found, triggering an import declaration. This
   then occludes the package name space.  But it leads to an error.

   I'd say that the function wildcard candidate was not a typename
   token, and so was never even considered as a viable binding.
   No import triggered; no error; package name space found; user's
   mind successfully read!

Since Françoise's reading leads to an error message, I think that
ours is a proper extension.  Notice that we do _not_ differ on
wildcard imported typenames: they must be acknowledges as typename
tokens even without being triggered for import (as I said, this is an
infamous but very popular HACK!)

Should the hack be standardized?  Not as such, but the two uses of
scope operator might need more separation so that classes are found
under "normal" resolution rules, and packages are found in the package
name space.  When they collide, the class wins.

Greg Jaxon



Steven Sharp wrote:
>> 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.