> Gordon Vreugdenhil wrote: > > Arturo, all other parameters can be access hierarchically via dotted expressions > in non-const contexts. It would be very irregular to not allow that here. > Everything you are saying is the reason to not allow the dotted form applies > to regular parameters in a hierarchical expression form as well. This does > not regularize things at all; it makes value parameters in classes truly > different than those in modules. I disagree. Not all parameters can be accessed via dotted expressions - certainly type parameters are not. The dotted form used to access parameters in hierarchical expressions is different from the dotted form used to access class member - hierarchical expressions are a static construct (even requiring constant indices) and IMHO analogous to the class resolution operator. A member select is a dynamic operation that depends on the run-time value of the handle. Hence, class dotted expressions and hierarchical dotted expressions are very different (overloaded) operations. My objection is based exclusively on the potential user confusion. I believe that it is valuable to keep these two concepts separate. I understand that what Francoise (and you) are proposing can be easily implemented. But, the mere fact that we're having this discussion means that this issue should not be resolved via an email vote and more discussion is needed. Arturo -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Wednesday, May 06, 2009 7:09 AM To: Arturo Salz Cc: Francoise Martinolle; Bresticker, Shalom; sv-ec@server.eda.org Subject: Re: [sv-ec] Definition of access for class parameters. 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, all other parameters can be access hierarchically via dotted expressions in non-const contexts. It would be very irregular to not allow that here. Everything you are saying is the reason to not allow the dotted form applies to regular parameters in a hierarchical expression form as well. This does not regularize things at all; it makes value parameters in classes truly different than those in modules. In particular, if one has mixes of design unit and class based design, disallow dotted parameter access can in fact be limiting since parameter hierarchical references would not be interchangeable with modules references. Gord > 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 Thu May 7 12:37:14 2009
This archive was generated by hypermail 2.1.8 : Thu May 07 2009 - 12:37:55 PDT