RE: [sv-ac] P1800 SV-AC: vote on #1549

Hi Dmitry,
 
it has to be considered in a broader context, hence have it as a
separate item.
 
ed
 


________________________________

	From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
	Sent: Thursday, October 05, 2006 2:33 AM
	To: Eduard Cerny; Lisa Piper; Bassam Tabbara; sv-ac@eda.org
	Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549 
	
	

	Hi Ed,

	 

	Implicit data type may be useful in functions, tasks, etc., and
I provided several examples of their usage ("implicit" was called
"anytype" in my proposal)

	 

	function bit majority (implicit a);

	            majority = 2 * $countones (a) > $bits (a); 

	endfunction

	 

	Also, it is not always convenient to place the untyped arguments
in the first place, especially when the typed argument has a default
value. E.g., 

	 

	sequence ev(s, e, int delay = 1);

	            s ##delay e;

	endsequence

	 

	Thanks,

	Dmitry

	 

	
________________________________


	From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org] On Behalf Of Eduard Cerny
	Sent: Monday, September 11, 2006 6:19 PM
	To: Lisa Piper; Bassam Tabbara; sv-ac@server.eda.org
	Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549 

	 

	I think that the issue is that we introduce a new keyword
"implicit" and there is generally resistance to introducing new keywords
that have a very narrow usage, in this case only in the list of
arguments to properties and sequences. Therefore, either the other
committees find it useful in other contexts or we perhaps may have to
retract it. In fact, it is not obvious to me that we do really need it,
because we could require that all untyped arguments be placed first on
the list.

	 

	Best regards

	ed

	 

		 

		
________________________________


		From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]
On Behalf Of Lisa Piper
		Sent: Monday, September 11, 2006 11:05 AM
		To: Bassam Tabbara; sv-ac@eda.org
		Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549 

		 

		 

		
________________________________


		From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]
On Behalf Of Bassam Tabbara
		Sent: Friday, September 08, 2006 1:54 PM
		To: sv-ac@eda.org
		Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549 

		 

		I vote No. I think voting now is rushed -- we need take
back to committee for more discussions on the following:

		 

		a) Clarify how the new types should be handled in
checking and error reporting and also in relation to the "true nature"
identification functions that Dmitry proposed (isSequence() etc...).
Currently it's not clear at all what compiler *shall* vs. may vs. ....
do if the type is different than nature, and what the user expectation
might be here .... [Note the proposal currently has a bunch of "may
be's" that bug me.]

		[Lisa Piper >>>] I did a search and see 3 "may ..." and
those statements say that <things> "may" be typed.  They might also be
untyped in which case no type checking will occur.    Is this what you
are referring to? 

		 

		How the "new types" should be handled in checking and
error reporting is a generic issue that applies to all types in all
functions, tasks, classes etc?  Do you see some conflict with Dmitry's
proposal?   

		b) "implicit" as we discussed before is handy
potentially for SV in general, that said, it should probably be added
elsewhere (with other types/qualifiers) and referenced here. So we
should check with other committees to find the best way to handle this
(incl. double-check on an existing/better way even) rather than add it
exclusively here.

		[Lisa Piper >>>] does using it here prevent it from
being used elsewhere?

		 

		Thx.

		-Bassam.