RE: [sv-ec] Re: Type parameters, typedefs, and general BNF semantics

This is similar to what used to be in the LRM in 1.4:

If the name of any category starts with an italicized part, it is
equivalent to the category name without the italicized part. The
italicized part is intended to convey some semantic information. For
example, "msb_index" and "lsb_index" are equivalent to "index." 
 
Shalom


________________________________

	From: owner-sv-ec@server.eda.org
[mailto:owner-sv-ec@server.eda.org] On Behalf Of Brad Pierce
	Sent: Wednesday, October 10, 2007 2:04 AM
	To: sv-ec@server.eda.org
	Subject: RE: [sv-ec] Re: Type parameters, typedefs, and general
BNF semantics
	
	
	The semantic prefixes are intended to be normative, as discussed
in
	 
	      <http://www.eda-stds.org/sv-ac/hm/2599.html>
http://www.eda-stds.org/sv-ac/hm/2599.html
	 
	If that's not clear enough in the LRM, it should be clarified.
	 
	-- Brad
	 

________________________________

	From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf
Of Randy Misustin
	Sent: Tuesday, October 09, 2007 10:23 AM
	To: Mark Hartoog
	Cc: Vreugdenhil, Gordon; SV_EC List; Mehdi Mohtashemi
	Subject: Re: [sv-ec] Re: Type parameters, typedefs, and general
BNF semantics
	
	
	Mark Hartoog wrote: 

		There already is a BNF rule, type_identifier, that
specifies where
		type parameters and typedefs can be used. 

	Hello all,
	
	Aren't we straying pretty far from reality here? The BNF
describes the grammar in terms of what lexical tokens constitute valid
sentences in SystemVerilog's syntax. As such, both class_identifier and
type_identifier derive the same rule (not surprisingly, named simply
identifier) in section A.9.3. Syntactially, class_identifier and
type_identifier are interchangeable.
	
	The distinctions being discussed here are semantic in nature and
derive from the normative text, not the BNF. It seems to me that either
interpretation is syntactically legal, according to the BNF. The
discussion should be what interpretation is semantically legal, and if
ambiguous or inconsistent, what's the appropriate remedy.
	
	-randy.
	
	Mark Hartoog wrote: 

		I think this kind of catch all language in the LRM is a
very bad idea.
		There already is a BNF rule, type_identifier, that
specifies where
		type parameters and typedefs can be used. If there are
places where it
		needs to be added, then we should consider those
proposals. This
		proposal
		is so vague that no one can understand what they might
be enabling by
		approving this. You want to allow typedefs and type
parameters anywhere
		"unless otherwise restricted". What exactly does that
phase mean.
		
		Consider a class declaration:
		
		class_declaration ::= // from A.1.2
		       [ virtual ] class [ lifetime ] class_identifier [
		parameter_port_list ]
		       [ extends class_type [ ( list_of_arguments ) ] ];
		       { class_item }
		endclass [ : class_identifier]
		
		Surely you are not suggesting that the declaration name
of the class can
		be a typedef or type parameter. Where is the restriction
for this? Is it
		just
		that it makes no sense?
		
		I think this change would only further confuse the
issue.
		
		> -----Original Message-----
		> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]
On
		> Behalf Of Gordon Vreugdenhil
		> Sent: Monday, October 08, 2007 3:13 PM
		> To: SV_EC List; Mehdi Mohtashemi
		> Subject: [sv-ec] Re: Type parameters, typedefs, and
general
		> BNF semantics
		>
		>
		>
		> Gordon Vreugdenhil wrote:
		> [...]
		> > I'll follow-up to this a bit later today with a
Mantis item and
		> > proposal to address what I think is the more
consistent and correct
		> > way in which to read the intent of the LRM in this
area.
		>
		>
		> I have filed Mantis 2087 on this issue and attached a
proposal.
		>
		> Mehdi, given the potential for substantial impact on
the
		> overall LRM if this proposal does not express the
intent of
		> the committee, could we address this at the next EC
meeting?
		>
		> Gord.
		> --
		>
--------------------------------------------------------------------
		> Gordon Vreugdenhil
503-685-0808
		> Model Technology (Mentor Graphics)
gordonv@model.com
		>
		>
		> --
		> This message has been scanned for viruses and
		> dangerous content by 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.
		
		
		


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