Re: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals

Hi Doron:

nexttime and s_nexttime are preferable to me.

J.H.

> X-eda.org-MailScanner-Watermark: 1205927762.08344@KdF2AAYUCCkEGyoqa9huEA
> X-Authentication-Warning: server.eda.org: majordom set sender to owner-sv-ac@eda.org using -f
> X-eda.org-MailScanner-Watermark: 1205927699.80559@MnIOr8knp23VKuKXj+2gUg
> X-ExtLoop1: 1
> X-IronPort-AV: E=Sophos;i="4.25,488,1199692800"; 
>    d="scan'208";a="353620775"
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Wed, 12 Mar 2008 13:54:19 +0200
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals
> thread-index: AciD75n1zsovK59NSSyDP6j6eoheDgAGE0ugAAvnTxAAAA2EEA==
> From: "Bustan, Doron" <doron.bustan@intel.com>
> Cc: <sv-bc@eda.org>, <sv-ec@eda.org>, <sv-cc@eda.org>, <sv-ac@eda.org>
> X-OriginalArrivalTime: 12 Mar 2008 11:54:25.0673 (UTC) FILETIME=[D1B99F90:01C88437]
> 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 server.eda.org id m2CBtOPq005504
> Sender: owner-sv-ac@eda.org
> X-eda.org-MailScanner-Information: Please contact the ISP for more information
> X-MailScanner-ID: m2CBtsAM005571
> X-eda.org-MailScanner-From: owner-sv-ac@server.eda.org
> 
> All,
> 
> anybody objects to Dmitry's suggestion?
> 
> Doron
> 
> >>-----Original Message-----
> >>From: Korchemny, Dmitry
> >>Sent: Wednesday, March 12, 2008 1:53 PM
> >>To: Bustan, Doron; Gordon Vreugdenhil; Brad Pierce
> >>Cc: sv-bc@server.eda.org; sv-ec@server.eda.org; sv-cc@server.eda.org;
> sv-
> >>ac@server.eda.org
> >>Subject: RE: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC
> >>proposals
> >>
> >>Hi Doron,
> >>
> >>I would suggest to change it to future and s_future.
> >>
> >>Regards,
> >>Dmitry
> >>
> >>-----Original Message-----
> >>From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
> On
> >>Behalf Of Bustan, Doron
> >>Sent: Wednesday, March 12, 2008 8:16 AM
> >>To: Gordon Vreugdenhil; Brad Pierce
> >>Cc: sv-bc@server.eda.org; sv-ec@server.eda.org; sv-cc@server.eda.org;
> sv-
> >>ac@server.eda.org
> >>Subject: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC
> proposals
> >>
> >>All,
> >>
> >>I will try to be proactive here. Does anybody object to changing the
> next
> >>and s_next LTL operators to LTL_next and s_LTL_next respectively?
> >>
> >>I know it is not visually attractive, but I am not sure that we will
> be
> >>able to converge on something else in time. One can always alias it to
> >>something else.
> >>
> >>Doron
> >>
> >>>>-----Original Message-----
> >>>>From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
> >>On
> >>>>Behalf Of Gordon Vreugdenhil
> >>>>Sent: Wednesday, March 12, 2008 5:15 AM
> >>>>To: Brad Pierce
> >>>>Cc: sv-bc@server.eda.org; sv-ec@server.eda.org;
> sv-cc@server.eda.org;
> >>sv-
> >>>>ac@server.eda.org
> >>>>Subject: Re: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals
> >>>>
> >>>>
> >>>>But adding "next" also invalidates the LRM itself (including 2005)
> in
> >>>>the builtin "Iterator" class which has:
> >>>>
> >>>>class List_Iterator#(parameter type T);
> >>>>    extern function void next();
> >>>>    extern function void prev();
> >>>>    extern function int neq( List_Iterator#(T) iter );
> >>>>    extern function int eq( List_Iterator#(T) iter );
> >>>>    extern function T data();
> >>>>endclass
> >>>>
> >>>>
> >>>>Gord.
> >>>>
> >>>>
> >>>>Brad Pierce wrote:
> >>>>> Steven,
> >>>>>
> >>>>> Thanks for running those tests.  Important data.  Just a short
> note
> >>>>> about your last point --
> >>>>>
> >>>>> The existing built-in enum method 'next()' needn't be a backward
> >>>>> compatibility problem for a new keyword 'enum'.  See friendly
> >>amendment
> >>>>> in bullet 11 here
> >>>>> <http://www.eda-stds.org/sv/sv-champions/hm/att-
> >>>>0340/pierce_email_vote_Feb2308.txt>.
> >>>>>
> >>>>> See also
> >>>>>
> >>>>>    http://www.eda-stds.org/sv-ac/hm/5668.html
> >>>>>
> >>>>> -- Brad
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
> Of
> >>>>> Steven Sharp
> >>>>> Sent: Tuesday, March 11, 2008 1:52 PM
> >>>>> To: stuart@sutherland-hdl.com; sv-bc@eda.org; sv-ec@eda.org;
> >>>>> sv-cc@eda.org; sv-ac@eda.org
> >>>>> Subject: Re: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals
> >>>>>
> >>>>>
> >>>>>  >From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
> >>>>>
> >>>>>  >I am very concerned about some of the proposed new keywords,
> >>>>specifically:
> >>>>>  >
> >>>>>  >  checker, free, global, implies, let, next, restrict, strong,
> >>until,
> >>>>>  > weak
> >>>>>  >
> >>>>>  >These are common English words that are likely to be in use as
> >>>>> >identifiers in existing code.
> >>>>>
> >>>>> I have tried compiling a suite of 88 customer designs with these
> >>>>> keywords reserved in our parser.  18 (or 20%) fail to compile.
> This
> >>>>> figure may be somewhat low, since some of these testcases appear
> to
> >>have
> >>>>> been run through obfuscators before being given to us.
> >>>>>
> >>>>> The offending keywords were:
> >>>>>
> >>>>> next:           7 testcases
> >>>>> free:           7 testcases
> >>>>> global:         4 testcases
> >>>>> checker:        1 testcase
> >>>>> weak:           1 testcase
> >>>>>
> >>>>> Note that the numbers do not add up to 18 testcases, because some
> >>>>> testcases failed with conflicts on more than one keyword.
> >>>>>
> >>>>> Also note that 'next' is particularly problematic, since it is
> >>already
> >>>>> used as an identifier in a built-in method in SV.  One of these
> >>customer
> >>>>> tests was SV and ran into this issue.
> >>>>>
> >>>>> Steven Sharp
> >>>>> sharp@cadence.com
> >>>>>
> >>>>>
> >>>>> --
> >>>>> 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* <http://www.mailscanner.info/>,
> >>and
> >>>>is
> >>>>> believed to be clean.
> >>>>
> >>>>--
> >>>>--------------------------------------------------------------------
> >>>>Gordon Vreugdenhil                                503-685-0808
> >>>>Model Technology (Mentor Graphics)                gordonv@model.com
> >>>>
> >>>>
> >>>>--
> >>>>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.
> >>
> 
> ---------------------------------------------------------------------
> 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.
> 
> 

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