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

OK, just to be clear, within a package, are we in agreement in both
intent and in LRM text to back it up that the following are legal
statements

package pkg;
   
class A;
   int m_i;
   virtual function void method;
     $display("A::method called"); 
   endfunction
endclass : A

//1. Parameterized type may be use to declare a member of a class
class B #(type T  = int); // or #(type T) without a default (mantis 907)
   T member = new();
   virtual function void method;
     $display("B::method called"); 
   endfunction
endclass : B

//2. Parameterized type may be a extend a class
class C #(type T = int) extends T;
   virtual function void method;
     super.method();
   endfunction
endclass : C

endpackage : pkg

module top;

   import pkg::*;
   C #(A) C_A = new();
   C #(B#(A))C_B_A = new();
   
   initial begin
      C_A.method();          // A::method called
      C_B_A.method();        // B::method called
      C_B_A.member.method(); // A::method called
   end
endmodule :  top 

Dave

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Arturo Salz
> Sent: Monday, October 08, 2007 5:28 PM
> To: Vreugdenhil, Gordon; SV_EC List
> Subject: RE: [sv-ec] Type parameters, typedefs, and general BNF
semantics
> 
> Gord,
> 
> On the first point you raised, you seem to have misunderstood what
Mark
> meant. He didn't mean that C++ disallows extending type parameters (or
> templated types) - although it is true of Java generics. I understood
> Marks's comment to mean that neither C++ nor Java have a concept of
> structural (or instantiation) hierarchy that would allow extension of
> class types across the structural hierarchy boundary. The BIG
difference
> between your C++ example and the problematic SV situation occurs when
> the base class is itself a parameter to an enclosing module. In that
> case, all sort of issues creep in, such as separate compilation and
> incomplete type information at parse time, or  the issue I raised
> regarding static members of classes extended across hierarchical
> boundaries. I believe we all agree that a parameterized class can be
> used as a base class, and there are no issues as long as the base
class
> is defined either in a package or in the same scope as the extended
> class. The problems begin when the base class is a hierarchical
> parameter.
> 
> 	Arturo
> 
> -----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.
> 


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