Re: [sv-bc] name resolution (some rules for consideration)

Mark Hartoog wrote:
> I have a few comments on this.
> 
>> 1. When a scope is finished its compilation, it is closed - 
>> no more symbol
>>     introduction.  The only exception is that an elaboration 
>> time "bind"
>>     can introduce additional instance names and implicit net 
>> names into
>>     the target scope.
> 
> Clearly generate can also introduce new names into a scope also. 

Not really.  That was determined by the 2005 rules.  The name
of a generate block (even its implicit external name) is a
name at the time of analysis *independent* of whether the block
is elaborated.  So the definition of the scope is still closed,
the only thing that you don't know is whether a candidate name
will actually exist (but you know all the candidates and whether
the candidate denotes a scope).


>> 2. within a method, an identifier reference is resolved by 
>> doing searches
>>     in the following order:
>>        1. bind into the local scope (upwards to the method 
>> declaration)
>>        1. bind into the local class
>>        2. bind to any inherited names
>>        3. bind following normal lexical/import/hierarchy 
>> rules in the parent
>>           scope of the local class decl
> 
> The question is when can you do this. If the base class can be
> a forward typedef or a type parameter, you cannot do this until
> elaboration.

Right.  There are a couple of potential directions for
resolving this, but as I noted in my preamble, I know that
this is not a complete set of rules, but we have to
start somewhere.

Unless you'd like to take a shot at writing up what you
believe are complete rules....


>> 5) in a dotted name, if the first/next name binds to a 
>> declaration that MAY
>>     permit a dot select , no backtracking occurs.
> 
> This seems very unclear to me. When is this rule applied? When
> the dotted name is first parsed? Or at elaboration? At elaboration
> time you should know what the value of the type parameters 
> are, so I'm guessing you are proposing to do this at parse time,
> which I think is an unworkable idea.

Please explain -- why is the "unworkable"?  The "may" contexts
are pretty easy to define and there are no legacy issues in
such cases.


> 
>> 6) In a hierarchical name, once a "bit select" is matched to 
>> a scope that permits
>>     a bit select, no backtracking
>>
>>     This means that once you've matched, for example, an 
>> arrayed generate name
>>     or an arrayed instance, you never backtrack upwards.
> 
> Why? Why do you allow any backtracking and forbid this backtracking?


Steven and I are philosophically agreed that backtracking is
a bad idea.  We want to limit the context of backtracking to
only those cases that are necessary to preserve legacy behavior.

In addition, user's would almost certainly find that if an
arrayed instance had bounds [1:10] and they referenced
index 11, that an error would be expected, not a search
up through the context tree.


>> 7) all class members are visible to the body of extern methods
> 
> This statement sounds fine, but the example after implies much more
> than this rule, and I disagree with the second example.


Yes, that has come up in discussions already.  There is disagreement
on that and I've specifically asked for suggestions about how to
resolve the disagreement.  I've received NO responses to that.
In lieu of any feedback, I guess we'll just have to disagree.

Gord.
-- 
--------------------------------------------------------------------
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.