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

Surya,

A different specialization within the class legal. Your example is not legal because "p" is not static hence the expression "C#(2)::p" is not legal in other contexts, but, if it were static, it would be legal.

        Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Surya Pratik Saha
Sent: Saturday, May 02, 2009 10:41 PM
To: Gordon Vreugdenhil
Cc: Alok Kumar Sinha; sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-bc] Issues regarding default specialization of class

Hi Gord,
One related question. Can we use specialization of class inside that
class declaration? Is the below mentioned e.g. valid?

class C #(int p = 1);
static task t;
int p;
int x = C #(2) ::p; // Is it illegal or legal ?
endtask
endclass

I am not clear from the LRM text.

Regards
Surya



-------- Original Message  --------
Subject: Re:[sv-bc] Issues regarding default specialization of class
From: Gordon Vreugdenhil <gordonv@model.com>
To: Alok Kumar Sinha <aksinha@cal.interrasystems.com>
Cc: sv-bc@eda.org, sv-ec@eda.org
Date: Wednesday, April 29, 2009 7:38:07 PM
> 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.




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.