Re: [sv-bc] Mantis 2674 and 2611 (ballot 123 and 131)

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Mon Apr 27 2009 - 22:46:12 PDT

Gordon Vreugdenhil wrote:

I don't like this change.  The issue is that
one would have to NOT report "C::x" as an error if "C"
was a variable and package "C" also exists.

Yes, but no change is involved.

  And what about if there is an inner variable "C" and a further
out type "C"?  Do we then bypass just the variable or
is the existence of an *earliest* lexical binding as
a non-type sufficient to look for a package?
  

Then the normal name resolution rule fails to turn up a lexically visible "C" that is a type;
therefore the package identifier resolves the name.  The wording as I gave it leads to that outcome.
But I can see where "previously declared" might be misread as "lexically more global".
I only put that phrase in to emphasize declaration before use, which is already a requirement
for type declarations and uses; if you think dropping this helps, that'd be OK.

Since this is pure lexical scoping, I don't think this
is a huge name conflict issue 

Yes, all these decisions are being made during lexical analysis, but nothing is being
added that isn't already required by the grammar rules themselves.  Being able to
distinguish declarations from some other statement types or from module instantiations
already requires us (parsers and readers) to distinguish typenames from data (and maybe
even from interface) names, and also to maintain these distinctions on a
stack that tracks the lexical binding scopes.  Just use that extant machinery again,
you've already bought and paid for it; make it do a little more good work.

and I don't like the
additional complexity of what you are suggesting.

The complexity was already there when packages arrived on the scene.
The only addition is a check of the symbol class you find with a fail-over to package lookup.
Why is that worth adding?  Because it makes the human reader's job much simpler.
There are typically fewer type names than there are variable and wire names in a design.
It's no good putting a variable or wire name as left operand of ::, and future SV won't
miss a potential meaning, since . already gives us an obvious syntax for inspecting
components or attributes of data.   Why crowd the reader's brain with a fog of
variable names that could not possibly be the intended meaning?  Why allow
package extractions to be interrupted by the prolific unbounded source of name collisions?
In a way, the rule I give resembles C++ namespace vs typename resolution which in their
case never collides with variable identifiers.

  I'd prefer to keep the rule a bit more tight at this point;
  

It's all in your definition of "tight" I guess.  I prefer to focus on the "tighter" set of
names for which the construct has a good meaning.

we can relax it in the future if there is sufficient
push-back that the more restrictive form causes real
problems.
  

I'm describing the rule we've been delivering for 2-3 major releases already.

But I humbly apologize for one misstatement I made earlier.  The left operand of
'::' can indeed trigger a wildcard import, if one is available.  If you'd like, we can discuss
whether this trigger is also conditional on the actual import being a type vs data name.
My recollection is that it only triggers import of a type, but that code is already so old
I'd need to run a testcase to confirm. 

Gord.

Greg Jaxon wrote:
  

Gordon Vreugdenhil wrote:
    

Mantis 2674 (fopen filename) and 2611 (package/class :: prefix
binding) have proposals in Mantis.
     http://www.eda-stds.org/mantis/view.php?id=2674
     http://www.eda-stds.org/mantis/view.php?id=2611
      

If the prefix name is resolved using the normal scope resolution
rules, the '::' shall denote the class resolution operator. Otherwise
the '::' shall denote the package resolution operator.
        

Based on our earlier exchanges on this subject, I have to
counter-propose this rewording of Sect 23.7.1:

If the left operand of the scope resolution operator :: resolves via the
normal scope resolution rules
*to a name previously declared as a type*, it shall denote the class
scope resolution operator (see 8.22).
Otherwise the '::' shall denote the package resolution operator.

Text in 8.22 could, but need not change to clarify this.

I feel there is at least a human factors reason to not let data names
shadow package names: there are just too many
places you need to look to track down a collision with a data name,
there are far fewer ways to declare type names.

Greg Jaxon

    

--
--------------------------------------------------------------------
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. Received on Mon Apr 27 22:47:26 2009