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

Brad,

 

The LRM states:

 

 

6.22.1 Matching types

Two data types shall be defined as matching data types using the
following inductive definition. If two data

types do not match using the following definition, then they shall be
defined to be nonmatching.

a) Any built-in type matches every other occurrence of itself, in every
scope.

b) A simple typedef or type parameter override that renames a built-in
or user-defined type matches

that built-in or user-defined type within the scope of the type
identifier.

...

 

That clearly means a type_identifier could semantically match any other
type.

 

I don't think it's possible to represent this in the BNF without
exploding type_identifier as an alternation with every other type.? 

 

Dave

 

 

________________________________

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Brad Pierce
Sent: Tuesday, October 09, 2007 5:04 PM
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. 

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