RE: [sv-ac] 1704, empty match, and local variable assignments

John,

Yes, this is what I meant.

Therefore, the expression

(a, v=val)[*0:$]

is OK, but

(a[*0:$], v=val) 

would be illegal. Correct?

ed

> -----Original Message-----
> From: John Havlicek [mailto:john.havlicek@freescale.com] 
> Sent: Tuesday, February 06, 2007 10:06 AM
> To: Eduard.Cerny@synopsys.COM
> Cc: john.havlicek@freescale.com
> Subject: Re: [sv-ac] 1704, empty match, and local variable assignments
> 
> Ed:
> 
> I don't think it is necessary.  I like the following:
> 
>     It is illegal to attach a sequence_match_item to a sequence that
>     admits an empty match.
> 
> There will need to be some analogous statement in 17.8 to prevent
> local variable assignments from being attached to sequences that 
> admit empty match.
> 
> J.H.
> 
> 
> > X-MimeOLE: Produced By Microsoft Exchange V6.5
> > Content-class: urn:content-classes:message
> > Date: Tue, 6 Feb 2007 05:55:12 -0800
> > Thread-Topic: [sv-ac] 1704, empty match, and local variable 
> assignments
> > Thread-Index: AcdJ6zHJVQnPD0iJTIuV9noEtzujvAACynwA
> > From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> > X-OriginalArrivalTime: 06 Feb 2007 13:55:14.0032 (UTC) 
> FILETIME=[6CD96F00:01C749F6]
> > 
> > Why is it necessary to put stress on "subroutine", rather than just
> > sequence_match_item?
> > 
> > ed
> > =20
> > 
> > > -----Original Message-----
> > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On=20
> > > Behalf Of John Havlicek
> > > Sent: Tuesday, February 06, 2007 7:33 AM
> > > To: piper@cadence.com
> > > Cc: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > > Subject: Re: [sv-ac] 1704, empty match, and local 
> variable assignments
> > >=20
> > > Hi Lisa:
> > >=20
> > > I like this idea.  I recommend changing
> > >=20
> > >    It is illegal to attach a subroutine, or any 
> sequence_match_item,
> > >    to an empty match.
> > >=20
> > > to
> > >=20
> > >    It is illegal to attach a subroutine, or any 
> sequence_match_item,
> > >    to a sequence that admits an empty match.
> > >=20
> > > J.H.
> > >=20
> > >=20
> > > > X-MimeOLE: Produced By Microsoft Exchange V6.5
> > > > Content-class: urn:content-classes:message
> > > > Date: Mon, 5 Feb 2007 18:47:10 -0500
> > > > X-MS-Has-Attach:=20
> > > > X-MS-TNEF-Correlator:=20
> > > > Thread-Topic: [sv-ac] 1704, empty match, and local variable=20
> > > assignments
> > > > Thread-Index: Acc/WJTmTM+3is1SQCq33XgaVC2NeQKJhQsA
> > > > From: "Lisa Piper" <piper@cadence.com>
> > > > X-Received: By mx-sanjose.cadence.com as l15NlCVC002190 at=20
> > > Mon Feb  5 15:47:12 2007
> > > > X-OriginalArrivalTime: 05 Feb 2007 23:47:16.0259 (UTC)=20
> > > FILETIME=3D[F7555F30:01C7497F]
> > > >=20
> > > > This is a multi-part message in MIME format.
> > > >=20
> > > > ------_=3D_NextPart_001_01C7497F.F57F7E59
> > > > Content-Type: text/plain;
> > > > 	charset=3D"us-ascii"
> > > > Content-Transfer-Encoding: quoted-printable
> > > >=20
> > > > Hi John,
> > > >=20
> > > > =3D20
> > > >=20
> > > > I would like to keep the handling of local variables=20
> > > consistent with the
> > > > treatment of all sequence_match_items. So to be consistent=20
> > > with the way
> > > > Annex E is already written, I think we should state that it=20
> > > is illegal
> > > > to attach any sequence_match_item to an empty match.  I'd=20
> > > like to get
> > > > feedback from the group and then I will update the 
> formal writeup.
> > > >=20
> > > > =3D20
> > > >=20
> > > > =3D20
> > > >=20
> > > > REPLACE:
> > > >=20
> > > > =3D20
> > > >=20
> > > > 17.9 Calling subroutines on match of a sequence
> > > >=20
> > > > Tasks, task methods, void functions, void function methods,=20
> > > and system
> > > > tasks can be called at the end of a successful match of a=20
> > > sequence.=3D20
> > > >=20
> > > > =3D20
> > > >=20
> > > > WITH:
> > > >=20
> > > > =3D20
> > > >=20
> > > > 17.9 Calling subroutines on match of a sequence
> > > >=20
> > > > Tasks, task methods, void functions, void function methods,=20
> > > and system
> > > > tasks can be called at the end of a successful 
> non-empty match of a
> > > > sequence. It is illegal to attach a subroutine, or any
> > > > sequence_match_item, to an empty match.
> > > >=20
> > > > =3D20
> > > >=20
> > > > Note that this section talks about Subroutines on 
> sequence match.  I
> > > > extended the second line to clarify that this applies to any
> > > > sequence_match_item since there were not other=20
> > > corresponding places to
> > > > state it.=3D20
> > > >=20
> > > > =3D20
> > > >=20
> > > > Lisa
> > > >=20
> > > > =3D20
> > > >=20
> > > > -----Original Message-----
> > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On=20
> > > Behalf Of John
> > > > Havlicek
> > > > Sent: Tuesday, January 23, 2007 8:38 PM
> > > > To: sv-ac@eda-stds.org
> > > > Subject: [sv-ac] 1704, empty match, and local variable 
> assignments
> > > >=20
> > > > =3D20
> > > >=20
> > > > All:
> > > >=20
> > > > =3D20
> > > >=20
> > > > I thought some this afternoon about 1704 and empty match=3D20
> > > >=20
> > > > assignments.
> > > >=20
> > > > =3D20
> > > >=20
> > > > It seems intuitive to me that if a sequence matches empty, then
> > > >=20
> > > > no local variable assignment within the sequence should be=3D20
> > > >=20
> > > > executed during that evaluation thread. =3D20
> > > >=20
> > > > =3D20
> > > >=20
> > > > It also seems intuitive that if a sequence matches 
> empty, then=3D20
> > > >=20
> > > > we do not want a local variable assignment attached to the=20
> > > sequence=3D20
> > > >=20
> > > > to execute during that evaluation thread. =3D20
> > > >=20
> > > > =3D20
> > > >=20
> > > > I think these are consistent with what is written in 1704 now.
> > > >=20
> > > > =3D20
> > > >=20
> > > > What we have currently in Annex E is
> > > >=20
> > > > =3D20
> > > >=20
> > > >    (R, v=3D3De)  \equiv  (R ##0 (1, v=3D3De))
> > > >=20
> > > > =3D20
> > > >=20
> > > > Notice that this says more, namely that if we attach a local
> > > >=20
> > > > variable assignment to a sequence, then the underlying 
> sequence=3D20
> > > >=20
> > > > is no longer allowed to match empty.  In other words, 
> Annex E=3D20
> > > >=20
> > > > today implies that
> > > >=20
> > > > =3D20
> > > >=20
> > > > (1)   (R, v=3D3De)  \equiv  (R intersect 1[*1:$], v=3D3De)
> > > >=20
> > > > =3D20
> > > >=20
> > > > (This looks clear to me, although I haven't written a proof.)
> > > >=20
> > > > I don't think there is anything wrong with this, but it might
> > > >=20
> > > > be criticized as too restrictive.  It is certainly not 
> saying the
> > > > following:=3D20
> > > >=20
> > > > =3D20
> > > >=20
> > > > (2)  (R, v=3D3De)  \equiv  (R intersect 1[*0]) or (R=20
> > > intersect 1[*1:$], =3D
> > > > v=3D3De)
> > > >=20
> > > > =3D20
> > > >=20
> > > > The righthand side of (2) says that if R matches empty,=20
> > > ignore the=3D20
> > > >=20
> > > > local variable assignment and go on; otherwise, perform 
> the local
> > > > variable=3D20
> > > >=20
> > > > assignment at the end of a non-empty match of R.
> > > >=20
> > > > =3D20
> > > >=20
> > > > Applying the flow rules to the RHS of (2) does no seem to=20
> > > be the right
> > > >=20
> > > > thing to do if R cannot match empty -- we get an artificial
> > > >=20
> > > > requirement that v flow in in order for v to flow out of (R, =
> > v=3D3De).
> > > >=20
> > > > On the other hand, if R can match empty, then applying the=20
> > > flow rules
> > > >=20
> > > > to the RHS of (2) seems to give the desirable condition 
> that v=3D20
> > > >=20
> > > > flow out of (R, v=3D3De) only if it flows in.
> > > >=20
> > > > =3D20
> > > >=20
> > > > We may want to think about changing the semantics of 
> (R, v=3D3De) =
> > from
> > > >=20
> > > > (1) to (2), but there may be some non-trivial work to 
> adapt the flow
> > > >=20
> > > > rules to work with this.  In any case, such a change 
> should be made
> > > >=20
> > > > with great care.
> > > >=20
> > > > =3D20
> > > >=20
> > > > Best regards,
> > > >=20
> > > > =3D20
> > > >=20
> > > > John H.
> > > >=20
> > > > =3D20
> > > >=20
> > > > --=3D20
> > > >=20
> > > > This message has been scanned for viruses and
> > > >=20
> > > > dangerous content by MailScanner, and is
> > > >=20
> > > > believed to be clean.
> > > >=20
> > > > =3D20
> > > >=20
> > > >=20
> > >=20
> > > --=20
> > > This message has been scanned for viruses and
> > > dangerous content by MailScanner, and is
> > > believed to be clean.
> > >=20
> > >=20
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.