RE: [sv-bc] operator naming

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
	Cc: 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] On Behalf Of Bresticker, Shalom
	Sent: Tuesday, September 18, 2007 12:08 PM
	To: sv-bc@server.eda-stds.org
	Cc: 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 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"

-- 
This message has been scanned for viruses and 
dangerous content by 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, and is
believed to be clean.