RE: [sv-ac] ballot on 1466

Lisa,

The problem I was mentioning is when you try to add new syntax from
another language; you get into situations (combinations of productions)
that didn't exist in that other language. Another issue is that similar
ranges are used in other places (coverage, inside operator, queues) and
the language starts to become irregular if you start allowing shortcuts
here, but not there.

This proposal may still be a good idea, but when you start to add up all
the other enhancements going in at the same short timeframe that we have
for the next LRM, this issue doesn't seem to be important enough to take
the risk.

This is a case with any project. You have to draw a line somewhere on
the number of new features or changes you can manage within a single
release.

> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
On
> Behalf Of Lisa Piper
> Sent: Friday, March 23, 2007 6:40 AM
> To: john.havlicek@freescale.com; sv-ac@server.eda-stds.org
> Subject: RE: [sv-ac] ballot on 1466
> 
> Hi all,
> 
> I have seen these shortcuts used a lot in PSL and I am not aware of
> issues with typos causing problems.
> 
> Lisa
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
John
> Havlicek
> Sent: Friday, March 23, 2007 7:50 AM
> To: sv-ac@eda-stds.org
> Subject: [sv-ac] ballot on 1466
> 
> Hi All:
> 
> Bassam's "no" vote on 1466 is enough to abort
> the email ballot, assuming that he will not change
> his vote before the ballot period expires.
> 
> The only technical modification I see that will
> help is to remove the [?] shortcut that was introduced
> by Dmitry.
> 
> I don't see any other technical modification of the
> proposal that will address his or Dave Rich's concerns.
> 
> Regarding the argument about dropping a digit and
> accidentally writing [*] instead of [*2], I think
> that, from a user's perspective, it is much more
> likely that this will be caught quickly due to
> the thread proliferation than, say, a mistake in
> counting in which [*3] is written instead of [*2].
> The second kind of mistake could easily lurk un-noticed
> for many simulation runs until missing coverage alerted
> the user to the problem.  The best defenses agains such
> mistakes that I am aware of are lint checking and human
> review.
> 
> The arguments about ROI seem only concerned with the
> tool builder's perspective.  In my opinion, the return
> from this enhancement has primarily to do with improving
> the human user's ability to write and read and review the
> code.
> 
> We can discuss this further in the next meeting.  At that
> point we should decide whether to modify the proposal or
> simply call for a voice vote.
> 
> J.H.
> 
> Ballot on Mantis 1466
> 
> - Called on 2007-03-22, final ballots due by 23:59 PDT on 2007-03-29.
> 
>  v[xxxxxxxxxxxxxxxxx-xx] Doron Bustan (Freescale)
> yv[xxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)
>  n[-------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
>  v[xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
>  t[xxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
>  v[xxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel - Co-Chair)
>  v[xxx----------xx-xxxx] Manisha Kulshrestha (Mentor Graphics)
>  v[-xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
>  n[-x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
> yv[x-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
>  n[-x..................] Erik Seligman (Intel)
>  n[---xxxx-xx----------] Tej Singh (Mentor Graphics)
> nv[xxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
> yv[xxxxx...............] Tom Thatcher (Sun Microsystems)
>    |-------------------- attendance on 2007-03-20
>  |---------------------- voting eligibility for this ballot
> |----------------------- email ballots received
> 
> 
> 	Legend:
> 		x = attended
> 		- = missed
> 		r = represented
> 		. = not yet a member
> 		v = valid voter (2 out of last 3)
> 		n = not valid voter
>                 t = chair eligible to vote only to make or break a tie
> 
> --
> 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.