RE: [sv-ac] RE: feedback to P1800 WG on ballot issues

From: Havlicek John-R8AAAU <john.havlicek_at_.....>
Date: Tue Apr 14 2009 - 07:33:55 PDT
Hi Shalom:
 
You are focusing on the "actual" substring in the BNF non-terminal.
 
I reasoned more abstractly.  Do tasks and functions have distinct
non-terminals in the positions of default argument and actual argument
in an instance?  I think that the answer is no.  This is the precedent
that Dmitry was referring to.  Regardless of what the actual
non-terminal is, are there distinct non-terminals in the productions for
tasks and functions.
 
J.H.

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Tuesday, April 14, 2009 4:04 AM
To: Korchemny, Dmitry; sv-ac@server.eda.org
Subject: [sv-ac] RE: feedback to P1800 WG on ballot issues


Sure.
I personally agreed with the comment, but I would not vote 'no' because
of it.
The only use in the BNF of actual_argument is in assertion constructs,
so you can't appeal to other parts of the BNF for precedent or
consistency.
 
Shalom


________________________________

	From: Korchemny, Dmitry 
	Sent: Tuesday, April 14, 2009 11:57 AM
	To: Bresticker, Shalom; sv-ac@server.eda.org
	Subject: RE: feedback to P1800 WG on ballot issues
	
	

	But the default argument is and actual argument - it is a
default actual argument. If we introduce new terminals for all possible
use cases, the BNF will become completely unmanageable. I think this
issue should be discussed by all committees to elaborate the common
methodology. I don't feel comfortable to such changes at the last
minute.

	 

	Regards,

	Dmitry

	 

	From: Bresticker, Shalom 
	Sent: Tuesday, April 14, 2009 9:20 AM
	To: Korchemny, Dmitry; sv-ac@server.eda.org
	Subject: RE: feedback to P1800 WG on ballot issues

	 

	The point is that they don't use "actual_function_argument".

	The use of "actual" is confusing.

	By your argument, sequence_actual_arg is also inconsistent with
tasks and functions, which use simply 'expression'.

	Note for example that there are many types of 'identifier' that
all reduce to 'identifier'.

	For example,

	array_identifier ::= identifier

	block_identifier ::= identifier

	Each is used where the semantics match the name, even though
they are syntactically identical. array_identifier is not used for
blocks, and block_identifier is not used for arrays.

	On the other hand, 'identifier' and 'expression' are generic
names with no semantic information about where they are used. They could
be used anywhere they are syntactially correct. But if you use a name
that has some semantic meaning, then you should not use it where the
meaning does not match its use.

	 

	Regards,

	Shalom

		
________________________________


		From: Korchemny, Dmitry 
		Sent: Tuesday, April 14, 2009 9:13 AM
		To: Bresticker, Shalom; sv-ac@server.eda.org
		Subject: RE: feedback to P1800 WG on ballot issues

		Hi Shalom,

		 

		But the tasks and functions do not use
default_function_argument, do they?

		 

		Dmitry

		 

		From: Bresticker, Shalom 
		Sent: Tuesday, April 14, 2009 7:57 AM
		To: Korchemny, Dmitry; sv-ac@server.eda.org
		Subject: RE: feedback to P1800 WG on ballot issues

		 

		Hi,

			 

			87  - Mantis 2649: sequence_actual_arg is used
to represent the default argument

			SV-AC believes that there is no added value in
introducing a new non-terminal identical to sequence_actual_arg.  It
would also introduce an inconsistency between the BNF of sequences on
the one hand, and the BNF of properties, functions, and tasks on the
other hand. Therefore SV-AC recommends to leave the text unchanged.
			[SB] Why would this be inconsistent with tasks
and functions? Tasks and function BNFs use simply "expression" for
default values. Module port defaults use "constant_expression". Neither
uses "actual" for "default".

			 

			As for properties, yes, the same problem exists
in the property BNF. I personally agree with the comment, though I did
not submit it.

			 

			Shalom 

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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Apr 14 07:35:59 2009

This archive was generated by hypermail 2.1.8 : Tue Apr 14 2009 - 07:36:08 PDT