Re: [sv-ec] Definition of access for class parameters.

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Wed May 06 2009 - 07:22:56 PDT
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