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

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.

	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