FWD, bounced email from Gord -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] Sent: Sunday, May 03, 2009 11:54 AM To: sv-ec-approval@eda.org Subject: BOUNCE sv-ec@eda.org: Non-member submission from ["Vreugdenhil, Gordon" <gordon_vreugdenhil@mentor.com>] Subject: RE: [sv-bc] Issues regarding default specialization of class Date: Sun, 3 May 2009 11:48:29 -0700 That is legal. There is no restriction on specializations like that. Any data type location is fine. This would be very similar to have an unparameterized class refer to its own type; that isn't specifically addressed either but the general assumption for any type (including specializations) should be that in the absence of a specific restriction, any use is valid. Gord -----Original Message----- From: Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com] Sent: Sat 5/2/2009 10:41 PM To: Vreugdenhil, Gordon Cc: Alok Kumar Sinha; sv-bc@eda.org; sv-ec@eda.org Subject: Re: [sv-bc] Issues regarding default specialization of class =20 Hi Gord, One related question. Can we use specialization of class inside that=20 class declaration? Is the below mentioned e.g. valid? class C #(int p =3D 1); static task t; int p; int x =3D 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=20 >> declaration, use of the class scope resolution >> operator shall be a reference to the name as though it was made=20 >> inside the parameterized class; no specialization >> is implied." >> >> Now for the example : >> >> class C #(int p =3D 1, type T =3D 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=20 >> 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=20 >> 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=20 >> class C. >> But it is difficult to detect the error, because it is clear that any=20 >> error for C::T can only be detected >> after function name is found during parsing. Is it the real intention=20 >> 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=20 >> forwardly declared. >> For e.g. , >> module top; >> typedef C; >> initial >> begin >> C:: x =3D 1; // Is the specialization is required or it= =20 >> 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 =3D 1, parameter type T =3D int ); >> static T x; >> endclass >> endmodule >> >> When C::x is declared we do not know whether C will a parameterized=20 >> class or not. >> >> The Mantis 1857 due to which the text added in the LRM is silent on=20 >> 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. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------_=_NextPart_001_01C9CC20.4E7938D3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7654.9"> <TITLE>RE: [sv-bc] Issues regarding default specialization of class</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <BR> <P><FONT SIZE=3D2>That is legal. There is no restriction<BR> on specializations like that. Any data type<BR> location is fine. This would be very similar<BR> to have an unparameterized class refer to its<BR> own type; that isn't specifically addressed either<BR> but the general assumption for any type (including<BR> specializations) should be that in the absence<BR> of a specific restriction, any use is valid.<BR> <BR> Gord<BR> <BR> -----Original Message-----<BR> From: Surya Pratik Saha [<A HREF=3D"mailto:spsaha@cal.interrasystems.com">m= ailto:spsaha@cal.interrasystems.com</A>]<BR> Sent: Sat 5/2/2009 10:41 PM<BR> To: Vreugdenhil, Gordon<BR> Cc: Alok Kumar Sinha; sv-bc@eda.org; sv-ec@eda.org<BR> Subject: Re: [sv-bc] Issues regarding default specialization of class<BR> <BR> Hi Gord,<BR> One related question. Can we use specialization of class inside that<BR> class declaration? Is the below mentioned e.g. valid?<BR> <BR> class C #(int p =3D 1);<BR> static task t;<BR> int p;<BR> int x =3D C #(2) ::p; // Is it illegal or legal ?<BR> endtask<BR> endclass<BR> <BR> I am not clear from the LRM text.<BR> <BR> Regards<BR> Surya<BR> <BR> <BR> <BR> -------- Original Message --------<BR> Subject: Re:[sv-bc] Issues regarding default specialization of class<BR> From: Gordon Vreugdenhil <gordonv@model.com><BR> To: Alok Kumar Sinha <aksinha@cal.interrasystems.com><BR> Cc: sv-bc@eda.org, sv-ec@eda.org<BR> Date: Wednesday, April 29, 2009 7:38:07 PM<BR> > See below.<BR> ><BR> ><BR> > Alok Kumar Sinha wrote:<BR> >> Hi,<BR> >><BR> >> I have two issues regarding default specialization of class:<BR> >><BR> >> 1) According to LRM P1800-2009-draft7a, section 8.24.1,<BR> >><BR> >> "In the context of a parameterized class method out-of-block<= BR> >> declaration, use of the class scope resolution<BR> >> operator shall be a reference to the name as though it was made<BR> >> inside the parameterized class; no specialization<BR> >> is implied."<BR> >><BR> >> Now for the example :<BR> >><BR> >> class C #(int p =3D 1, type T =3D int);<BR> >> extern static function T f();<BR> >> endclass<BR> >> function C::T C::f();<BR> >> return p + C::p;<BR> >> endfunction<BR> >><BR> >> So, for the return type of function 'f', any specialization = is not<BR> >> required as the function is itself a method of that class<BR> >> and is only declared outside.<BR> >><BR> >> But one of the standard simulaters which supports this type of<BR> >> semantic check, is failing on the csae and is expecting<BR> >> a specialization for return type too.<BR> >> Am I missing something or is it a simulater bug.<BR> ><BR> ><BR> ><BR> > The above kind of example was not clearly defined in the LRM<BR> > for 2005 and the text you are quoting came in rather late<BR> > in the 2009 process. This is certainly a "bug" but a v= ery<BR> > understandable one in that it does take time for implementations<BR> > to reflect late changes (particularly since this is still just<BR> > in balloting!).<BR> ><BR> ><BR> ><BR> ><BR> >> Here I also want to raise an implementation issue.<BR> >><BR> >> If the function is defined as :<BR> >> function C::T f();<BR> >> return p + C::p;<BR> >> endfunction<BR> >><BR> >> It is definitely an error as this function is not the method of th= e<BR> >> class C.<BR> >> But it is difficult to detect the error, because it is clear that = any<BR> >> error for C::T can only be detected<BR> >> after function name is found during parsing. Is it the real intent= ion<BR> >> of the LRM?<BR> ><BR> ><BR> > Yes, that is the intent.<BR> ><BR> > The reverse case is much worse -- if C::T implied the<BR> > default specialization then you'd have no reasonable way to<BR> > deal with the earlier case (unless you conceptually "undid"<= BR> > the specialization).<BR> ><BR> > Making the "C::T" have context dependent specialization<BR> > semantics was deemed to be way too confusing -- many users<BR> > already don't really understand default specialization<BR> > and having C::T mean different things would not help.<BR> ><BR> ><BR> >><BR> >> 2. How can we decide for any specialization if any class is<= BR> >> forwardly declared.<BR> >> For e.g. ,<BR> >> module top;<BR> >> typedef C;<BR> >> initial<BR> >> begin<BR> >> = C:: x =3D 1; // Is the specialization is required o= r it<BR> >> is an error ?<BR> ><BR> ><BR> > You cannot tell at this point. You can only determine that this<= BR> > is an error once you see the actual class declaration.<BR> ><BR> ><BR> ><BR> >> end<BR> >> class C #(parameter int p =3D 1, parameter type = T =3D int );<BR> >> static T x;<BR> >> endclass<BR> >> endmodule<BR> >><BR> >> When C::x is declared we do not know whether C will a parameterize= d<BR> >> class or not.<BR> >><BR> >> The Mantis 1857 due to which the text added in the LRM is silent o= n<BR> >> that.<BR> >><BR> >> Please anyone give suggestion regarding this.<BR> ><BR> ><BR> > I can't really give suggestions on your implementation; there<BR> > are many implementation level details that impact how you<BR> > decide to do this. The basic approach would have to involve<BR> > deferring the decision until later and "back patching" the<B= R> > actual use.<BR> ><BR> > Gord.<BR> <BR> <BR> <BR> <BR> </FONT> </P> </BODY> <br />--=20 <br />This message has been scanned for viruses and <br />dangerous content by <a href=3D"http://www.mailscanner.info/"><b>MailScanner</b></a>, and is <br />believed to be clean. </HTML> ------_=_NextPart_001_01C9CC20.4E7938D3-- -- 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.Received on Sun May 3 11:59:46 2009
This archive was generated by hypermail 2.1.8 : Sun May 03 2009 - 12:00:28 PDT