I hadn't addressed the ref issue in my previous response. Arturo, your response implies that you think that a const var can be used for a "ref". Certainly that can't be the case. I agree that a "const" can be used with a "const ref" but a const var is not assignable which is what a ref requires. Gord. Arturo Salz wrote: > Gord, > > I appreciate what you're saying, but allowing parameters does create several subtle issues that don't exist with const properties. For example, a parameter cannot be passed by reference whereas a const property can (it cannot be written but it can be passed and read). A parameter can be used to specify the size of static arrays, but a dotted expression may not be. I believe all these cases become normalized by restricting access to parameters via the class scope operator. I don't see this as reducing the expressive power of the language, and it does provide one simple rule for all parameters (value or type). > > Arturo > > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Tuesday, May 05, 2009 6:24 PM > To: Arturo Salz > Cc: Francoise Martinolle; Bresticker, Shalom; sv-ec@server.eda.org > Subject: Re: [sv-ec] Definition of access for class parameters. > > Arturo, > > "const" class properties are also not proper L-values yet they can > have "dotted" access (in fact they must unless they are static). > > I don't see any reason to limit access to value parameters as via > ".". Type parameters are not quite the same as value parameters > and in other situations we haven't tried to insinuate that they > are either. So I don't see any reason for claiming that they > must be the same here. A type parameter (or a typedef) is > different than a value parameter, localparam, or "const var". > > Gord. > > Arturo Salz wrote: >> Francoise, >> >> I added the following note to Mantis 2575: >> >> I don't think we should allow access to parameters via dotted expressions - handle.parameter or super.parameter. Parameters should >> be accessible only via the class resolution operator. This is simple and straightforward rule, otherwise we have to make distinctions >> between value parameters and type parameters and that is only bound to cause confusion. >> >> Parameters are not class members in the sense that they don't represent proper L-values. They exist only in the compiler and they >> may not be written. >> >> That was my intent on mantis 2598 - where I would expect to add the note that parameters are accessible only via the :: operator. >> >> Arturo >> >> -----Original Message----- >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Francoise Martinolle >> Sent: Tuesday, May 05, 2009 10:25 AM >> To: Bresticker, Shalom; Gordon Vreugdenhil >> Cc: sv-ec@server.eda.org >> Subject: RE: [sv-ec] Definition of access for class parameters. >> >> >> I uploaded the proposal to mantis # 2575. >> The proposal I submitted takes care of several mantis items. It was a >> decision we >> made to treat mantis items 2575, 2608 and 2598 together in one proposal. >> >> Francoise >> ' >> >> -----Original Message----- >> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] >> Sent: Tuesday, May 05, 2009 4:57 AM >> To: Francoise Martinolle; Gordon Vreugdenhil >> Cc: sv-ec@server.eda.org >> Subject: RE: [sv-ec] Definition of access for class parameters. >> >> Where? I don't see it. >> It should be Mantis 2608. >> >> Shalom >> >>> -----Original Message----- >>> From: Francoise Martinolle [mailto:fm@cadence.com] >>> Sent: Monday, May 04, 2009 9:23 PM >>> To: Bresticker, Shalom; Gordon Vreugdenhil >>> Cc: sv-ec@server.eda.org >>> Subject: RE: [sv-ec] Definition of access for class parameters. >>> >>> >>> New proposal considering your comments has been uploaded to Mantis. >>> >>> Francoise >>> ' >>> -----Original Message----- >>> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] >>> Sent: Sunday, May 03, 2009 12:28 AM >>> To: Francoise Martinolle; Gordon Vreugdenhil >>> Cc: sv-ec@server.eda.org >>> Subject: RE: [sv-ec] Definition of access for class parameters. >>> >>> Hi, >>> >>> This is the first time I have looked at this. >>> >>> The term "parameter", unless specifically qualified as "value >>> parameter" >>> or "type parameter", is a generic term including both. If the term >>> "parameter" is intended to specify only value parameters, it needs to >>> say so explicitly. On the other hand, if both are meant, there is no >>> need to specify both. >>> >>> Thus, for example, where 8.17 says, "Class parameters and class local >>> parameters are also public," this includes both value and type >>> parameters. >>> >>> Where 8.22 says, "A class parameter, type parameter or local param is >>> a public element of a class," the use of "type parameter" is redundant >>> because it is included in "class parameter". >>> >>> The text should be consistent in order to avoid confusion. >>> >>> The use of "local param" should be avoided. It should be either "local >>> parameter" or "localparam". >>> >>> At the end of the proposal, on page 4, there is some extra text. >>> >>> Thanks, >>> Shalom >>> >>>> -----Original Message----- >>>> From: owner-sv-ec@server.eda.org >>>> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Francoise >>> Martinolle >>>> Sent: Saturday, May 02, 2009 1:31 AM >>>> To: Gordon Vreugdenhil >>>> Cc: sv-ec@server.eda.org >>>> Subject: RE: [sv-ec] Definition of access for class parameters. >>>> >>>> >>>> Second version of the class parameter specification which addresses >>>> Gordon's comments. >>>> >>>> -----Original Message----- >>>> From: Gordon Vreugdenhil [mailto:gordonv@model.com] >>>> Sent: Friday, May 01, 2009 4:54 PM >>>> To: Francoise Martinolle >>>> Cc: sv-ec@eda.org >>>> Subject: Re: [sv-ec] Definition of access for class parameters. >>>> >>>> Francoise, this looks pretty good to me. Thanks for >>> working through >>>> the details there. >>>> >>>> One detail lies in the grammar -- a constant_primary only admits a >>>> ps_parameter_identifier which does allow the syntactic form >>> name::name >>> >>>> but where the LRM uses package_name to indicate intent for >>> the prefix. >>>> Ideally I think that should be fixed in the grammar. >>>> We might also consider explicitly stating that >>> class_type::parameter >>>> is a constant expression. That likely isn't needed with >>> the grammar >>>> change, but it makes the asymmetry with the "this." and "super." >>>> more explicit and obviously intentional. >>>> >>>> Gord. >>>> >>>> Francoise Martinolle wrote: >>>>> Attached is a proposal for specifying access to class >>>> parameters, type >>>> >>>>> parameters and local class parameters. >>>>> >>>>> Mantis is not working so I have not uploaded the proposal. >>>>> >>>>> Francoise >>>>> ' >>>>> >>>>> -- >>>>> This message has been scanned for viruses and dangerous content by >>>>> *MailScanner* <http://www.mailscanner.info/>, and is >>> believed to be >>>>> clean. >>>> -- >>>> -------------------------------------------------------------------- >>>> 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. >>>> >>>> >>> --------------------------------------------------------------------- >>> Intel Israel (74) Limited >>> >>> This e-mail and any attachments may contain confidential material for >>> the sole use of the intended recipient(s). Any review or distribution >>> by others is strictly prohibited. If you are not the intended >>> recipient, please contact the sender and delete all copies. >>> >>> >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution by >> others is strictly prohibited. If you are not the intended recipient, >> please contact the sender and delete all copies. >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> > > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > -- -------------------------------------------------------------------- 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 May 6 07:25:42 2009
This archive was generated by hypermail 2.1.8 : Wed May 06 2009 - 07:28:18 PDT