Re: [sv-bc] Issues regarding default specialization of class

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Wed Apr 29 2009 - 07:08:07 PDT
See below.


Alok Kumar Sinha wrote:
> Hi,
> 
> I have two issues regarding default specialization of class:
> 
> 1) According to LRM P1800-2009-draft7a, section 8.24.1,
> 
> "In the context of a parameterized class method out-of-block 
> declaration, use of the class scope resolution
> operator shall be a reference to the name as though it was made inside 
> the parameterized class; no specialization
> is implied."
> 
> Now for the example :
> 
> class C #(int p = 1, type T = int);
>    extern static function T f();
> endclass
> function C::T C::f();
>    return p + C::p;
> endfunction
> 
> So, for the return type of function 'f',  any specialization is not 
> required as the function is itself a method of that class
> and is only declared outside.
> 
> But one of the standard simulaters which supports this type of semantic 
> check, is failing on the csae and is expecting
> a specialization for return type too.
> Am I missing something or is it a simulater bug.



The above kind of example was not clearly defined in the LRM
for 2005 and the text you are quoting came in rather late
in the 2009 process.  This is certainly a "bug" but a very
understandable one in that it does take time for implementations
to reflect late changes (particularly since this is still just
in balloting!).




> Here I also want to raise an implementation issue.
> 
> If the function is defined as :
> function C::T f();
>    return p + C::p;
> endfunction
> 
> It is definitely an error as this function is not the method of the 
> class C.
> But it is difficult to detect the error, because it is clear that any 
> error for C::T can only be detected
> after function name is found during parsing. Is it the real intention of 
> the LRM?


Yes, that is the intent.

The reverse case is much worse -- if C::T implied the
default specialization then you'd have no reasonable way to
deal with the earlier case (unless you conceptually "undid"
the specialization).

Making the "C::T" have context dependent specialization
semantics was deemed to be way too confusing -- many users
already don't really understand default specialization
and having C::T mean different things would not help.


> 
> 2.  How can we decide for any specialization if any class is forwardly 
> declared.
> For e.g. ,
> module top;
>    typedef     C;
>    initial
>        begin
>            C:: x = 1;     // Is the specialization is required or it is 
> an error ?


You cannot tell at this point.  You can only determine that this
is an error once you see the actual class declaration.



>        end
>    class C #(parameter int p = 1, parameter type T = int );
>        static T x;
>    endclass
> endmodule
> 
> When C::x is declared we do not know whether C will a parameterized 
> class or not.
> 
> The Mantis 1857 due to which the text added in the LRM is silent on that.
> 
> Please anyone give suggestion regarding this.


I can't really give suggestions on your implementation; there
are many implementation level details that impact how you
decide to do this.  The basic approach would have to involve
deferring the decision until later and "back patching" the
actual use.

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.
Received on Wed Apr 29 07:16:27 2009

This archive was generated by hypermail 2.1.8 : Wed Apr 29 2009 - 07:17:31 PDT