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

>Brad's response is "fix the BNF for constructors". 

I didn't say that.

-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Monday, October 08, 2007 2:32 PM
To: SV_EC List
Subject: [sv-ec] Type parameters, typedefs, and general BNF semantics

Mark and Brad have recently been making an argument for interpreting the
BNF in a manner that would disallow using type parameters in places in
which "class_identifier" is used in the grammar.

If followed consistently, the arguments being made lead to substantial
issues throughout the LRM.

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.

There are apparently three arguments that are being made; I address each
in detail here.


(1) C++ doesn't do this
=======================

In http://www.eda-stds.org/sv-ec/hm/4862.html  Mark says:

    I do not see how this can be interpreted to already allow type
    parameters to be used to specify the base class. To me it is clear
    that is an extension of the existing LRM and it is one that should
    be made very carefully.

    Neither C++ or Java templates allow this.

The last is a factually incorrect statement.

Here is an example of C++ code that does exactly what is claimed to be
illegal:

    template <class T> class C : public T { public: T my_base; } ;

    class D { public:
                int x;
                static int y;
            };
    int D::y;

    int main () {
      C<D> * a = new C<D>;
      a->x = 1;
      C<D>::y = 1;
    }

The above is accepted by Gnu, Sun, and AIX compilers and is consistent
with my reading of the 1998 ANSI/ISO C++ LRM.

I fail to see how:

    template <class T> class C : public T { public: T my_base; } ;

differs in fundamentals from the SV form:

    class C #(type T) extends T;
       T my_base;
    endclass





(2) The LRM is "clear" on this
==============================

Both Brad and Mark have made the argument that the LRM is "clear" on
this issue.  Dave Rich has observed that this narrow interpretation
causes problems with constructor calls.  Brad's response is "fix the BNF
for constructors".
    (See http://www.eda-stds.org/sv-ec/hm/4865.html)


The entire exchanged misses the point of just how deep the LRM approach
is at odds with the claimed intent.

The LRM does not, for example, expect that an "array_identifier"
should be *known* at compile time to be an array.  Such an expectation
is equivalent to the claim for type parameters.

The LRM also doesn't cover typedefs in terms of use of
"class_identifier"
or similar.  And I won't even get into the untyped formals that exist in
the assertions parts of the language.

So, if the committees agree that the intent of the LRM is as narrow as
what was suggested, there is a huge amount of work that is going to be
required.

I simply don't believe that it is reasonable to read the LRM's intent as
being as narrow as suggested.

If one accepts that types and parameters are first-class elements of the
language, then the BNF is *semantically* consistent in these areas --
the "identifer" restrictions are semantic resolution restrictions that
must be enforced at some point but not necessarily at compile/analysis
time.  If an "array_identifier" is simply a name that ends up denoting
an object of an array type, why does it not directly follow that a
"class_identifier" is simply a name that ends up denoting a class type?





(3) Extension from type parameters poses different problems
===========================================================

Mark has suggested that extension from type parameters is causing all of
the issues.  I do not agree with that interpretation at all.

As I discussed in the name resolution slides, all of the fundamental
issues have parallels in different areas.

Inline randomization constraints have the same problems with identifier
visibility as occurs in methods with inheritance from a type parameter.
A typedef from an interface (i.e.
"typedef intf.T myT") has all of the same "opaque" name issues as do
type parameters.

Mark has argued that the special resolution into inline constraints is
required and that there are substantial backwards compatibility issues
for any change there.  And in fact Mark's proposed resolution rules are
very careful to account for such scenarios.  How are the parameterized
class issues different?




Summary
=======


Although I agree that there are a few narrow issues that have arisen
during discussion of the name resolution issues, the issues are in fact
narrow ones that lend themselves to reasonable directed solutions.  I
completely agree that references to types in classes denoted by type
parameters is problematic and don't object to narrow restrictions in
terms of the use of "::" in that space.

I would prefer that we work together to find reasonable
solutions.   I have already suggested a form by parallel
with the interface typedef form.  If that isn't acceptable, Mark can
certainly propose alternatives.  However, such a blanket and wide
ranging change as is being suggested is simply unwarranted and poses
such substantial issues that it must be dismissed.




Resolving this core interpretation issue needs to be addressed
immediately due to the potential of wide impact within the LRM.


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.