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

Arturo,

You have mentioned your discomfort with "instance based"
parameterization a few times on an informal basis.

I could not read Mark's suggestions in that way at all -- he
was making a broad restriction based on the BNF.  All
forms would be impacted by Mark's suggestion.

Even if the intent was the less restrictive form that you
are suggesting, I would still have serious objections.

The current LRM does not distinguish between different
kinds of type parameters within the system and to introduce
such a distinction at this point would be a substantial and
incompatible restriction to the LRM.  There is no basis in
the LRM for any assumption that type parameters are
determinable at any particular time within the analysis;
as such there is no basis for arguing that a restriction
in only some cases is warranted.  If such cases posed
fundamentally new problems in terms of the LRM rules or
unimplementable, that may be different.  However, in
the face of combinations of nested classes, inline constraints,
and interface typedefs, all of the issues exist in other
contexts.  Any argument to the contrary would have to
rely on assumptions regarding when various forms of
type parameterization were resolved and there is no
basis for that in the LRM.

If type parameters are first-class in the language,
one must be prepared to deal with them as such.  It is
certainly possible to implement to that; an existence proof
exists and handles the interesting cases that you mention --
separate compilation, static members, etc.

The only questions that I have raised in this area are
with regards to name resolution issues that have parallels
in the other situations.  Finally, as I noted in the
name resolution context, my issues in terms of Mark's
proposed rules were not implementation issues but rather
issues related to long-term design reuse and reasoning
about the code by the end-user.  In this context, the
restrictions you are suggesting or the more extreme ones
Mark stated are fundamentally different -- they restrict actual
functionality without having any ability to express something
comparable and are a true loss of expressiveness in the
language.

If you would like to make your proposed restrictions more
definite, it would make this easier to debate.  At this
point the descriptions of exactly what you believe should
constitute a valid relationship seem somewhat imprecise.

Gord.


Arturo Salz wrote:
> 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.