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

A bit of additional follow-up on this.

After additional reflection, I am actually quite comfortable with
the language I proposed.

In the context that you quote, the BNF is not nearly
"complete" in any case.  It is clear from the overall
LRM that a class declaration is what **introduces** a
class_identifier, but that is not expressed purely by
the BNF.  It is obvious that someone needs to consider
non-BNF text to understand when a "class_identifier"
implies a reference and when it implies the introduction
of a new class_identifier.

I don't think it is unreasonable at all to expect one
to understand that it is only in a *reference* context
that use of a typedef name or type parameter is permitted
to substitute for the class_identifier.

In addition, clearly the "class_identifier" in a declaration
context can be any kind of simple identifer -- a typedef
name, a variable name, a design unit name, or a new identifier
that doesn't have a pre-existing semantic qualification.  That
is because this is introducing the identifier as a semantically
qualified name.  But there is no indication purely from the BNF
that this particular context is *introducing* the class_identifier.


I don't understand where you want the grammar to go.
Do you really expect to express all semantic relationships
in the BNF?  That would not be a reasonable expectation and
I can't imagine that you want to go there.  Do you really think
that people will read this and expect that the class_declaration
context is not introducing the name as a class_identifier?


Finally, as to the "Unless otherwise restricted" clause -- I
added that so that we would not have to revisit this language
if reasonable restrictions for name resolution were introduced.
In particular, I think that we both agree that the LRM cannot
allow "type_parameter::type_name" in a general type context.
That at least will need a restriction.  By having this clause
we can add a restriction for that case without causing a
new contradiction or revisiting this statement of intent.

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.