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

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Mon Oct 08 2007 - 20:50:46 PDT
Mark, as I said originally,  I very much welcome any
rewording and/or clarification on this.  The crucial
thing is that the intent is agreed on.  The suggestion
that only a class_identifier can be used in an extension
is a huge restriction to the intent and the justification
on a BNF basis simply exacerbates the issue.

If you are after a specific restriction, which is what
Arturo is alluding to, make a specific proposal along
that front.  At least that will clarify what you are
after.

Gord.

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

-- 
--------------------------------------------------------------------
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.
Received on Mon Oct 8 20:51:07 2007

This archive was generated by hypermail 2.1.8 : Mon Oct 08 2007 - 20:51:31 PDT