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
---------------------------------------------------------------------



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