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

Hi Stu,
 
I think that the problem with attributes is that there are no "reserved"
attributes. I recall that we discussed that option but then discarded
it. Strength, like other operators, should be part of the language.
 
Best regards,
ed
 


________________________________

	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Stuart Sutherland
	Sent: Tuesday, September 18, 2007 2:05 PM
	To: sv-bc@eda-stds.org; sv-ac@eda-stds.org
	Subject: 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 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 <http://www.mailscanner.info/>
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. 


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