Re: [sv-ec] classes questions

Let me generalize this one step further and consider the
name resolution implications.

class C #(type T = bit; int P = 1);
    extern function T[P] f(T a);
endclass

typedef double T;
localparam P = 2;

function T[P] C::f(T a);
    ...
endfunction


The resolution of "T[P]" as the return type of C::f
is, well, interesting.

When we parse the formal "T a" we can easily know
that we are in the context of "C".  But for T[P], this
isn't so easy.

Consider as well if we have:
    function C::T[C::P] C::f(T a);

That should be the same as the other definition, yes?  If so,
one needs to determine that C::T and C::P do not refer to
the default specialization (i.e. are NOT type resolution)
but are simpler "scope" resolutions into the unspecialized
parameterized class.  One can't know that until it is
determined that the function name is C::f.  If you had:
    function C::T[C::P] f(T a);
that would make C::T and C::P references into the default
specialization since this isn't an external function
definition.

I may go back to my earlier position and say that C::name
should never refer to the default specialization since otherwise
we have a pretty nasty disambiguation issue.

If we require C#()::x rather than C::x then we can easily
determine what is going on.  Further, if we require the
parameterized class name prefix for implied class references
in the return types for external functions, then the name
resolution problems go away.  Such an approach would require
the latter form of the function in the external context
but that doesn't seem too bad.

Gord


Gordon Vreugdenhil wrote:

> 
> Brad Pierce wrote:
> 
>> Gord,
>>
>>
>>> The grammar actually requires a "class_identifier" as the prefix of
>>
>>
>> "::".
>>
>> Where does the grammar do this?  The BNF doesn't. Do you mean the
>> unboxed text in the first paragraph of 7.21?  
> 
> 
> Yes.  I didn't check that with the full grammar which does allow
> the more general form.  So C#(1)::x is allowed.  Given that,
> treating C::x as a reference into the default specialization
> is quite reasonable.
> 
> 
>>
>> The BNF does not even support the example on the next page
>>
>>     Base::print( Base::hex, 66 );
> 
> 
> 
> Hmm - apparently this was overlooked wasn't it.  method_call
> covers all the non-static cases, but not the static cases.
> It looks like ps_or_hierarchical_tf_identifier should just have
> a class_scope variant added to it.
> 
> 
>> For consistency with the rest of the BNF, I'd expect that a static
>> method or class property could be prefixed with any class_scope.
> 
> 
> Static class properties are covered I think.  A primary is
> permitted to have a class_scope before the "hierarchical_identifier"
> portion of the name.  Blocking assignments are also covered.
> 
> Gord
> 
>> Following is the BNF for class_scope --
>>
>>    class_scope ::= class_type ::
>>
>>    class_type ::=  ps_class_identifier [ parameter_value_assignment ]
>>                       { :: class_identifier [ parameter_value_assignment
>> ] }
> 
> 
> 
> 
>> -- Brad
>>
>> -----Original Message-----
>> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
>> Gordon Vreugdenhil
>> Sent: Tuesday, October 17, 2006 9:20 PM
>> To: Arturo Salz
>> Cc: Francoise Martinolle; sv-ec@eda.org
>> Subject: Re: [sv-ec] classes questions
>>
>> Arturo,
>>
>> I am somewhat Ok with allowing things like C::x, but in our experience,
>> users have had more difficulty in distinguishing that C::x does NOT mean
>> "the only x in the type C" but rather that it means "the x in the type
>> created by a default specialization of C".  This tends to be less an
>> issue when using C explicitly in a type construction context.
>>
>> The grammar actually requires a "class_identifier" as the prefix of
>> "::".  I think there is a distinction in that allowing "C::x" confuses
>> the idea of "class type" and "parameterized class as a type
>> constructor".
>>
>> Our basic approach so far has been to allow a default specialization
>> only in a context in which an explicit specialization would be
>> permitted.  Since the current BNF doesn't allow C#(1)::x, we don't allow
>> C::x.  Since the BNF does allow any of:
>>     typedef C#(1) C_1_type;
>>     C#(1) some_obj;
>>     class D extends C#(1); .... endclass; (and a few others), we allow
>> default specialization in those contexts.
>>
>> This was an LRM interpretation judgement call; I would certainly be in
>> favor of a clarification here.
>>
>> If we would allow explicit specialization in any of the other contexts,
>> I'd be more amenable to allowing implicit specialization as well even
>> though I think that allowing it can be quite confusing.
>>
>> Gord.
>>
>>
>> Arturo Salz wrote:
>>
>>
>>> Gord,
>>>
>>> I agree with most of what you wrote. But, I disagree with your last
>>> statement:
>>>
>>> Given the declaration:
>>>
>>>    class C #(int p = 1);
>>>       static int x = p;
>>>    endclass
>>>
>>> Then C::x does indeed mean "the x in the type created by the default 
>>> specialization". Otherwise, what's the point of providing a default 
>>> parameter?
>>> Why would you allow     typedef C xyz;    // this does mean the 
>>> default specialization
>>> But not allow C::x ? BTW, what about the form "C()::x"? That is very 
>>> clear that it means the default specialization.
>>>
>>> Another question regarding this is:
>>>
>>>    class D #(int p = 1);
>>>       enum Bool { FALSE, TRUE = p };
>>>    endclass
>>>
>>> Would you disallow "D::Bool" , but allow "typedef X D::Bool" ?
>>>
>>> I would agree with your assessment if Brad's proposal to omit default 
>>> types passes and the parameterized class were written with no default.
>>>
>>>     Arturo
>>>
>>
>> -- 
>> --------------------------------------------------------------------
>> Gordon Vreugdenhil                                503-685-0808
>> Model Technology (Mentor Graphics)                gordonv@model.com
>>
>>
> 

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