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.