Re: [sv-ec] question about name resolution in classes

Arturo Salz wrote:
> Gord,
> 
> I'm not sure I understood Francoise's suggestion. I believe she was
> trying to come up with some form of formalization that indeed causes
> lexical binding to take priority over other types of name binding (and
> any formalization would be a good thing). However, I believe that
> searching the outer scopes BEFORE the class hierarchy will inevitably
> result in the wrong thing. I feel rather strongly that binding the
> reference to i in method dump to child.i is absolutely wrong. Any rules
> that lead us to that conclusion should be quickly discarded.

I agree (for the determinable cases).  I don't think that one can
determine the binding statically in all cases; that is where my
example came from and what I am after -- rules for what constitutes
a non-determinable resolution and for what happens in such cases.

I wasn't trying to imply any agreement in my prior post, just trying
to make sure that I understood Francoise.

See my follow-up to Francoise's clarifications.

Gord.



> 	Arturo
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Gordon Vreugdenhil
> Sent: Thursday, March 23, 2006 10:28 PM
> To: francoise martinolle
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] question about name resolution in classes
> 
> Fancoise,
> 
> I'd like to make sure that I understand your thinking here -- I
> think that you are suggesting that normal lexical and
> package name binding should occur *before* class hierarchical
> resolution, is that correct?
> 
> In particular, given a simpler example of my example:
> 
>     module child;
>        int i;
>        class base;
>            int i;
>        endclass
>        class derived extends base;
>            function void dump;
>                $display(i);
>            endfunction
>        endclass
>     endmodule
> 
> your view would be that the reference to "i" inside
> derived::dump would refer to child.i and not to
> the property in base.  If the user wanted to refer
> to the property in base, they would have to use
> super.i (or possibly this.i).  Is that a correct
> understanding of your description?
> 
> Gord
> 
> 
> 
> francoise martinolle wrote:
> 
>> 
>>Gordon,
>>
>>That is an interesting sophisticated example where the base class is
> 
> not
> 
>>known until elaboration.
>>I agree that there are some lexical ways for removing ambiguity in
> 
> which
> 
>>scope to resolve a
>>symbol (this, super). If we follow the normal verilog name resolution
> 
> rules,
> 
>>in your example, since there is a child.i, i would resolve to child.i
>>
>>My opinion is that if there was an import p::*, then the parser needs
> 
> to
> 
>>attempt to resolve
>>the symbol by looking up in the package. The package look up is now
> 
> part of
> 
>>name resolution
>>as I had pointed out before. 
>>If the user needs to specify that i is a property of the class
> 
> hierarchy,
> 
>>super.i needs
>>to be used. If the symbol is not resolved at that point (no import and
> 
> no
> 
>>static i), I would
>>think that in your case we ought to consider 'i' as an oomr which may
> 
> be
> 
>>resolved at
>>elaboration. We should only consider this last resort because type of
> 
> the
> 
>>immediate scope
>>containing the symbol 'i' is not known until elaboration and i because
> 
> it is
> 
>>a simple name
>>needs to be resolved in that scope.
>>That scope is not *complete* until elaboration.
>>This is a new case of oomrs. Usually (with the exceptions of functions
> 
> and
> 
>>tasks) an oomr
>>consists of more than 1 token separated by '.'
>>
>>In summary, I expect the following:
>>
>>During parsing, normal Verilog name resolution rules (augmented by
>>systemVerilog package look up)
>>apply, 
>>then if the symbol is still undefined and the scope in which it
> 
> appears is a
> 
>>type which is
>>not known until elaboration, then the symbol is an oomr which is
> 
> resolved at
> 
>>elaboration when the type
>>is known.
>>
>>Another approach is to avoid the oomr for simple name and require that
> 
> i be
> 
>>resolved at parsing time.
>>However if super.i is used, allow the oomr to be resolved at
> 
> elaboration.
> 
>>Francoise
>>    '
>>
>>-----Original Message-----
>>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> 
> Gordon
> 
>>Vreugdenhil
>>Sent: Thursday, March 23, 2006 6:40 PM
>>To: francoise martinolle
>>Cc: sv-ec@eda.org
>>Subject: Re: [sv-ec] question about name resolution in classes
>>
>>Francoise,
>>
>>This is an area that is quite a bit more interesting than even your
> 
> example.
> 
>>The basic question is how to align lexical (and package) search rules
> 
> with
> 
>>class member and property lookup.
>>
>>In the package case (such as yours), since the package is required to
> 
> exist,
> 
>>the resolution of the base type is required to be known, so I think
> 
> the
> 
>>intuitive answer is that "i" is the member reference and needs to be
>>resolved as such.  It isn't clear to me however that this is going  to
> 
> end
> 
>>up being the answer.
>>
>>There are other contexts which are far more difficult since there are
>>separate compilation issues that come into play.
>>
>>Consider:
>>
>>    module child;
>>       parameter type T = int;
>>
>>       int i;
>>       class derived extends T;
>>           function void dump;
>>               $display(i);
>>           endfunction
>>       endclass
>>    endmodule
>>
>>    package p;
>>       class base;
>>           bit b;
>>       endclass
>>    endpackage
>>
>>    module top;
>>       class base;
>>          int i;
>>       endclas
>>
>>       child #(base) c1();
>>       child #(p::base) c2();
>>    endmodule
>>
>>In this scenario, what does "i" mean in class derived?  You can't
> 
> possibly
> 
>>know what it is or whether it is even lexically resolved to child.i or
>>resolved in the context of the class hierarchy.
>>In my example, the answer changes in the different module instances.
>>
>>Since module child is a valid module for separate compilation there is
> 
> no
> 
>>way to determine the answer at compilation; elaboration time is the
> 
> earliest
> 
>>at which this can be resolved.
>>
>>This is complicated by the package import rules.
>>If you didn't have "i" declared in "child" but it was potentially
> 
> visible,
> 
>>would you do the import and make it actually visible?
>>
>>One reasonable approach to the general problem is to require a "this."
> 
> or
> 
>>"super." prefix for references to inherited members in at least some
>>situations.
>>
>>I don't think there is any ideal solution to the naming issue since
> 
> you
> 
>>either have to deal with syntax requirements or have to try to define
> 
> some
> 
>>reasonable rules for when an implementation is required to know things
> 
> about
> 
>>the inheritance structure and when the user is required to
> 
> disambiguate.
> 
>>This is loosely related to the issues with randomize() that Ray and I
> 
> have
> 
>>been working on a proposal to address.
>>
>>Gord.
>>
>>
>>francoise martinolle wrote:
>>
>>
>>>Supposed I have a base class in a package and I create a derived class
> 
> 
>>>of that class in a module. I do not import the package but I use the 
>>>package scope syntax to indicate the base class. Does this cause all 
>>>the class item declaration of the BASE class to be visible in the 
>>>derived class?
>>>
>>>I think it should.
>>>
>>>
>>>package p;
>>>class BASE;
>>> rand logic i;
>>>endclass
>>>endpackage
>>>
>>>
>>>module top;
>>>class derived extends p::BASE;
>>>      constraint c1 { i == 1'b1};
>>>endclass
>>>endmodule
>>>
>>
>>
>>--
>>--------------------------------------------------------------------
>>Gordon Vreugdenhil                                503-685-0808
>>Model Technology (Mentor Graphics)                gordonv@model.com
>>
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com