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

From a user's point of view, I do not care for the use of angle brackets.  I
am OK with appending $ to the end of the operator names, but like appending
"_st" or "_strong" better than $ ("st" is used as an abbreviation for
"strong" in Verilog strengths).
 
Has defining a special attribute that can be used on these operators, such
as (* strong *), been discussed?  That would document the intent of the code
for both users and tools without adding more keywords.  It would also be
extendable to additional operators, constraints or other parts of the
language without having to add even more keywords in the future.  

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898


 


  _____  

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Bresticker, Shalom
Sent: Tuesday, September 18, 2007 3:32 AM
To: Feldman, Yulik; sv-bc@server.eda-stds.org
Cc: sv-ac@server.eda-stds.org
Subject: [sv-ac] RE: [sv-bc] operator naming


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  <http://www.mailscanner.info/> 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  <http://www.mailscanner.info/> 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.