RE: [sv-ac] RE: [sv-bc] operator naming

Hi Neil,

In principle, this notation can be used, but its definition will be
tricky, especially if you have some operators under negation - the
negation inverts the operator weakness.

Thanks,
Dmitry

-----Original Message-----
From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM] 
Sent: Thursday, September 20, 2007 3:37 AM
To: Korchemny, Dmitry
Cc: Adam Krolnik; Bresticker, Shalom; Feldman, Yulik;
sv-bc@eda-stds.org; sv-ac@eda-stds.org
Subject: Re: [sv-ac] RE: [sv-bc] operator naming

Hi Dmitry,

Does something like the following help?

  strong {a until next b}

Neil



Korchemny, Dmitry wrote On 09/18/07 08:20 AM,:
> Unfortunately it is hardly readable, e.g.:
> 
>  
> 
> a strong until strong next b
> 
>  
> 
> Regards,
> 
> Dmitry
> 
>  
> 
>
------------------------------------------------------------------------
> 
> *From:* owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> *On Behalf Of *Adam Krolnik
> *Sent:* Tuesday, September 18, 2007 5:00 PM
> *To:* Bresticker, Shalom
> *Cc:* Feldman, Yulik; sv-bc@server.eda-stds.org;
sv-ac@server.eda-stds.org
> *Subject:* Re: [sv-bc] operator naming
> 
>  
> 
> 
> Hello all;
> 
> If you want clarity, then make 'strong' a keyword so you have "strong
> always"  instead of strong_always.
> 
> Bresticker, Shalom wrote:
> 
> I like this suggestion.
> 
> As one who is always talking about clarity, I should have thought of
it
> myself.
> 
>  
> 
> Regards,
> 
> Shalom
> 
>      
> 
>
------------------------------------------------------------------------
> 
>     *From:* Feldman, Yulik
>     *Sent:* Tuesday, September 18, 2007 12:26 PM
>     *To:* Bresticker, Shalom; sv-bc@server.eda-stds.org
>     <mailto:sv-bc@server.eda-stds.org>
>     *Cc:* sv-ac@server.eda-stds.org <mailto:sv-ac@server.eda-stds.org>
>     *Subject:* RE: [sv-bc] operator naming
> 
>     Since the operators in angle brackets represent the strong
versions
>     of the corresponding operators, why not to depict that fact in
their
>     names, by naming these operators like "strong_always" or
"s_always".
>     This will make the language and the code easier to understand. If
>     there is a concern of introducing new keywords, then I would say
>     that readability of the code is much more important than a very
>     unlikely backward incompatibility, which can be workarounded by
>     features like 'begin/end_keywords directives, tool-specific
language
>     compatibility options or simple fixing of the code. A rare
backward
>     incompatibility issue may be fixed, but, if the operators are
>     unclearly named, the reduced readability will stay forever.
> 
>      
> 
>     --Yulik.
> 
>      
> 
>
------------------------------------------------------------------------
> 
>     *From:* owner-sv-bc@server.eda.org
>     <mailto:owner-sv-bc@server.eda.org>
>     [mailto:owner-sv-bc@server.eda.org] *On Behalf Of *Bresticker,
Shalom
>     *Sent:* Tuesday, September 18, 2007 12:08 PM
>     *To:* sv-bc@server.eda-stds.org <mailto:sv-bc@server.eda-stds.org>
>     *Cc:* sv-ac@server.eda-stds.org <mailto:sv-ac@server.eda-stds.org>
>     *Subject:* [sv-bc] operator naming
> 
>      
> 
>     Hi,
> 
>     SV-AC is working on a proposal (Mantis 1932) to introduce LTL
>     operators. Never mind for now what they do.
> 
>     Their problem is one of naming. There are two versions of each
>     operator. The question is how to name the alternate version.
> 
>     For example, if one operator is 'always', then two suggestions for
>     its dual are '<always>', and 'always$'.
> 
>     Are either of these acceptable as a naming convention, or does
>     anyone have a better suggestion?
> 
>     Thanks,
>     Shalom
> 
>     Shalom Bresticker
>     Intel Jerusalem LAD DA
>     +972 2 589-6852
>     +972 54 721-1033
> 
> ---------------------------------------------------------------------
> 
> 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 <http://www.mailscanner.info/>*MailScanner*
>     <http://www.mailscanner.info/>**, 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 <http://www.mailscanner.info/>, and
is
> believed to be clean. **
> 
> **
> 
> **
> 
> **-- **
> 
> **    Soli Deo Gloria**
> 
> **    Adam Krolnik**
> 
> **    Director of Design Verification**
> 
> **    VeriSilicon Inc.**
> 
> **    Plano TX. 75074**
> 
> **    Co-author "Assertion-Based Design"**
> 
> *---------------------------------------------------------------------
> 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 <http://www.mailscanner.info/>**MailScanner*
> <http://www.mailscanner.info/>*, 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. *

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-276-6385
Frontend Technologies (FTAP)                      Fax: 408-276-5092
Sun Microsystems                       email: neil.korpusik@sun.com
---------------------------------------------------------------------
---------------------------------------------------------------------
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.