Re: [sv-ac] part 1 of 1667

Hi Doron:

Thanks for your quick review.

> 1. page 3,item before last:
> 
>   "It shall be an error if the local variable formal
>    argument is unassigned at the completion of a match of the instance
> of  =20
>    the named sequence."
> 
>    It read like a run time test? I would like an elaboration time
> criteria
>    that determine whether an instantiation is legal.=20

My intention is that this is an elaboration time test based
on the rules of local variable flow.  Do you think that this
needs to be reworded?

> 2. I think that there should be a little bit more text connecting the
> new  =20
>    Use of local variables with local formal arguments and the "old
> style" =20
>    where local variables are used as actual arguments to un-typed
> variables.

O.k.  But it will be helpful if you can outline what technical points
are to be made.

> 3. A general comment that applies to both part1 and part2: I think that
> we=20
>    need a restriction that disallow using the same reference to local
> 
>    variable as an actual argument to more then one formal argument of=20
>    direction/output/inout.
>    The current definition define a non deterministic outcome according
> to =20
>    the order of the assignments in the match item list.

I agree with this.  This was an oversight on my part, as I think
you have pointed this out to me before.

J.H.

> X-ExtLoop1: 1
> X-IronPort-AV: E=Sophos;i="4.24,225,1196668800"; 
>    d="scan'208";a="354246167"
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Mon, 31 Dec 2007 14:00:19 +0200
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] part 1 of 1667
> Thread-Index: AchLEtGp9C5t8bZaS4y+iQpEgbklrAAe0c4A
> From: "Bustan, Doron" <doron.bustan@intel.com>
> X-OriginalArrivalTime: 31 Dec 2007 12:00:17.0666 (UTC) FILETIME=[B5C97E20:01C84BA4]
> 
> Hi John,
> 
> My comments for part 1 below:
> 
> 1. page 3,item before last:
> 
>   "It shall be an error if the local variable formal
>    argument is unassigned at the completion of a match of the instance
> of  =20
>    the named sequence."
> 
>    It read like a run time test? I would like an elaboration time
> criteria
>    that determine whether an instantiation is legal.=20
> 
> 2. I think that there should be a little bit more text connecting the
> new  =20
>    Use of local variables with local formal arguments and the "old
> style" =20
>    where local variables are used as actual arguments to un-typed
> variables.
> 
> 
> 3. A general comment that applies to both part1 and part2: I think that
> we=20
>    need a restriction that disallow using the same reference to local
> 
>    variable as an actual argument to more then one formal argument of=20
>    direction/output/inout.
>    The current definition define a non deterministic outcome according
> to =20
>    the order of the assignments in the match item list.
> 
> 
> I don't have more comments for part2.
> 
> Doron
> 
> >>-----Original Message-----
> >>From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
> On
> >>Behalf Of John Havlicek
> >>Sent: Sunday, December 30, 2007 8:35 PM
> >>To: sv-ac@server.eda.org
> >>Subject: [sv-ac] part 1 of 1667
> >>
> >>Hi Folks:
> >>
> >>I'm not sure if the attachment was too big, so I
> >>am sending this note without attachment.
> >>
> >>I have uploaded part 1 (non-Annex-F) of the proposal
> >>for 1667 to Mantis.
> >>
> >>I believe that Doron and Ed volunteered to review it.
> >>
> >>I will now begin work on the Annex F changes.
> >>
> >>J.H.
> >>
> >>--
> >>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.
> 

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