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

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Tue Oct 09 2007 - 17:03:59 PDT
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, and is
believed to be clean.
Received on Tue Oct 9 17:04:32 2007

This archive was generated by hypermail 2.1.8 : Tue Oct 09 2007 - 17:05:19 PDT