RE: [sv-ac] call to vote on 1549

Brad,

I agree, but the subject of Mantis 1982 is not whether the wording of
6.20.2.1 is optimal, but whether the description of 16.7 regarding $ is
consistent with the rest of the LRM. It isn't. 

(The BNF supplements the text in any case, so that even though 6.20.2.1
is missing the word 'only', the BNF implicitly adds it.)

I'll add your comment to Mantis 1350, though.

Thanks,
Shalom  

> -----Original Message-----
> From: owner-sv-ac@server.eda.org 
> [mailto:owner-sv-ac@server.eda.org] On Behalf Of Brad Pierce
> Sent: Monday, August 20, 2007 10:08 AM
> To: sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] call to vote on 1549
> 
> Shalom,
> 
> It's clear from the BNF, of course, (and I personally believe 
> it was the intent of IEEE Std 1800-2005) that a parameter is 
> the only kind of data object that can be assigned '$' (via 
> constant_param_expression in A.8.3), but that doesn't change 
> what the statement in 6.20.2.1 says and doesn't say.
> 
> What it *should* say is
> 
>       1)  An integer parameter is the only sort of data 
> object that can be assigned '$'.  
> 
>       2)  An integer parameter that has been assigned '$' can 
> only be legally referred to in contexts where '$' would 
> anyway be legal, as described in Footnote A.10.21.
> 
> -- Brad
> 
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Sunday, August 19, 2007 11:42 PM
> To: Brad Pierce; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] call to vote on 1549
> 
> Brad,
> 
> Look at the BNF.
> 
> Shalom 
> 
> > -----Original Message-----
> > From: owner-sv-ac@server.eda.org
> > [mailto:owner-sv-ac@server.eda.org] On Behalf Of Brad Pierce
> > Sent: Monday, August 20, 2007 9:38 AM
> > To: sv-ac@server.eda-stds.org
> > Subject: RE: [sv-ac] call to vote on 1549
> > 
> > >Does the statement in 6.20.2.1 actually imply that $ can 
> be assigned
> > only
> > >to parameters and then only to ones of integer types?
> > 
> > No, it doesn't.  It says that
> > 
> >     1)  An integer parameter can be assigned '$'.  (Perhaps 
> there are 
> > other sorts of data objects that can be assigned '$', 
> perhaps not, but
> 
> > this statement is silent on that issue.)
> > 
> >     2)  An integer parameter that has been assigned '$' can only be 
> > legally referred to in contexts where '$' would anyway be legal.
> > 
> > -- Brad
> > 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of 
> > John Havlicek
> > Sent: Sunday, August 19, 2007 3:10 PM
> > To: shalom.bresticker@intel.com
> > Cc: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > Subject: Re: [sv-ac] call to vote on 1549
> > 
> > Hi Shalom:
> > 
> > This is interesting.  We have thought for a long time that $ can be 
> > passed as actual argument to sequence and property 
> instances.  I think
> 
> > tools support this too.
> > 
> > Does the statement in 6.20.2.1 actually imply that $ can be 
> assigned 
> > only to parameters and then only to ones of integer types?  That is 
> > not the way I read it.
> > 
> > I also do not like the turn of phrase
> > 
> >   "An actual argument can replace any of the following:"
> > 
> > 
> > Best regards,
> > 
> > J.H.
> > 
> > > X-ExtLoop1: 1
> > > X-IronPort-AV: E=Sophos;i="4.19,281,1183359600"; 
> > >    d="scan'208";a="284779936"
> > > X-MIMEOLE: Produced By Microsoft Exchange V6.5
> > > Content-class: urn:content-classes:message
> > > Date: Sun, 19 Aug 2007 11:57:00 +0300
> > > X-MS-Has-Attach: 
> > > X-MS-TNEF-Correlator: 
> > > Thread-Topic: [sv-ac] call to vote on 1549
> > > Thread-Index: AcfgwmImOfiRY4IgSZCSHsE6gjltOABeqaNg
> > > From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> > > Cc: <sv-ac@eda-stds.org>
> > > X-OriginalArrivalTime: 19 Aug 2007 08:57:02.0177 (UTC) 
> > > FILETIME=[E89C8510:01C7E23E]
> > > 
> > > John,
> > > 
> > > I looked at this a little.
> > > 
> > > Mantis 1350 discusses ambiguities with respect to the use 
> of $, but 
> > > the basic restrictions are stated at the beginning of 6.20.2.1:
> > > 
> > > "The value $ can be assigned to parameters of integer types. A 
> > > parameter to which $ is assigned shall only be used
> > wherever $ can be
> > > specified as a literal constant."
> > > 
> > > Assigning $ to a variable does not fit those criteria.
> > > Nor does passing $ as an argument.
> > > You mentioned passing $ "as actual argument expression to a typed 
> > > formal argument."
> > > I do not see that it could be passed even to an untyped formal
> > argument.
> > > 
> > > I doubt even that what is written in 16.7 meets those criteria:
> > > 
> > > "An actual argument can replace any of the following:
> > >  ...
> > >  - Upper delay range or repetition range if the actual
> > argument is $"
> > > 
> > > Regards,
> > > Shalom
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: John Havlicek [mailto:john.havlicek@freescale.com]=20
> > > > Sent: Friday, August 17, 2007 2:32 PM
> > > > To: Bresticker, Shalom
> > > > Cc: Bustan, Doron; Yaniv.Fais@freescale.com; sv-ac@eda-stds.org
> > > > Subject: Re: [sv-ac] call to vote on 1549 =20  Hi Shalom:
> > > >=20
> > > > Lisa and I had a discussion yesterday about the example 
> in=20  the
> > > >1549 proposal.
> > > >=20
> > > > I do not think the LRM as it stands now allows $ to be=20
> >  assigned
> > > >to a variable or passed as actual argument=20  expression
> > to a typed
> > > >formal argument.  Do you know otherwise?
> > > >=20
> > > > The main conceptual issue that I see with allowing $ to be=20 
> > > >assigned to a variable or passed as actual argument=20
> > expression to
> > 
> > > >a typed formal argument is defining what value=20  it has in the 
> > > >space of possible values for the associated data type.
> > > >=20
> > > > It doesn't seem quite right to me to say that if $ is=20
> > assigned
> > > >to a shortint, for example, then the value is the=20  
> largest one 
> > > >that can be represented in an shortint.  On the=20  other
> > hand, maybe
> > 
> > > >this is a useful and sensible definition. =20  With 
> definitions of 
> > > >this kind, the meaning of $ is dependent=20  on the data 
> type into 
> > > >which it is assigned or to which it is=20  bound, but there is 
> > > >already precedent for that in the various=20  coercion rules.
> > > >=20
> > > > I recommended that we avoid this problem altogether for
> > now=20  and
> > > >not allow $ to be assigned to a variable or passed as=20  actual 
> > > >argument expression to a typed formal argument.  I=20  
> recommended 
> > > >that Lisa change the example to pass $ to a=20  context formal 
> > > >argument.
> > > >=20
> > > > J.H.
> > > >=20
> > > > > X-Authentication-Warning: server.eda-stds.org: majordom set=20
> > > > sender to=20
> > > > > owner-sv-ac@eda.org using -f
> > > > > X-ExtLoop1: 1
> > > > > X-IronPort-AV: E=3DSophos;i=3D"4.19,269,1183359600";=20
> > > > >    d=3D"scan'208";a=3D"118117813"
> > > > > X-MIMEOLE: Produced By Microsoft Exchange V6.5
> > > > > Content-class: urn:content-classes:message
> > > > > Date: Thu, 16 Aug 2007 09:15:58 +0300 X-MS-Has-Attach:=20 
> > > > > X-MS-TNEF-Correlator:=20
> > > > > Thread-Topic: [sv-ac] call to vote on 1549
> > > > > Thread-Index: =
> > > AcfeiQ52OKcMoqhRQC+dKxDIPbJwOwADZVDwABotlYAAMwPDUA=3D=3D
> > > > > From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> > > > > Cc: <sv-ac@eda-stds.org>
> > > > > X-OriginalArrivalTime: 16 Aug 2007 06:15:59.0713 (UTC)=20 
> > > > >FILETIME=3D[EA184510:01C7DFCC]
> > > > > X-eda.org-MailScanner: Found to be clean, Found to be clean
> > > > > X-Spam-Status: No, No
> > > > > X-MIME-Autoconverted: from quoted-printable to 8bit by=20 
> > > > >server.eda-stds.org id l7G6GDdJ019035
> > > > > Sender: owner-sv-ac@eda.org
> > > > > X-eda.org-MailScanner-Information: Please contact the ISP for 
> > > > >more=20  information
> > > > > X-eda.org-MailScanner-From: 
> owner-sv-ac@server.eda.org =20  The 
> > > > >LRM states in other places restrictions on the use of 
> $.=20  The 
> > > > >question is whether the example fulfills those conditions.
> > > > >=20
> > > > > The following quoted wording is a little unclear:=20 =20
> > > > > > An actual argument can replace any of the following:
> > > > > > - Identifier
> > > > > > - Expression
> > > > > > - Event control expression
> > > > > > - Upper delay range or repetition range if the actual=20
> > > > argument is $
> > > > >=20
> > > > > "can replace" seems a little problematic here.
> > > > > An actual argument cannot really replace an expression. E.g., 
> > > > >it=20  cannot replace a+b. It can replace a formal argument 
> > > > >which=20
> > > > is used as=20
> > > > > an expression, which is a little different.
> > > > >=20
> > > > > And does this list cover all the possibilities, or is it=20
> > > > just intended=20
> > > > > to be examples?
> > > > >=20
> > > > > And does the last item mean:
> > > > > 1. If the actual argument is $, it can be used only in this=20
> > > > way? If it=20
> > > > > is not $, can it be used in this way?
> > > > > 2. It can be used in this way only if it is $? If it is $,=20
> > > > can it be=20
> > > > > used in another way?
> > 
> > --
> > 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.
> > 
> 
> --
> 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.