[sv-bc] RE: [sv-ec] RE: Resolution of inherited type names

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Mark Hartoog
> Sent: Monday, September 10, 2007 11:19 AM
> To: Vreugdenhil, Gordon; Mark Hartoog
> Cc: SV_EC List; SV_BC List
> Subject: [sv-ec] RE: Resolution of inherited type names
> 
> There are two issues with your example. One is that
> it is generally assumed that type names are known at
> parse time.
[DR] I think I would use stronger language: Type names are required to
be known at parse time. Can we agree on that simple point?
> The use of the type operator solves that
> problem in cases where the type name may not be known
> at parse time. In your example, if you wrote:
> 
>       module child #(type T = int);
>         int T2;
>         class C extends T;
>            T::T2 x;
>         endclass
>       endmodule
> 
> You still would not know at parse time if T::T2 was a
> type name, although you would know that 'T2' was suppose
> to resolve in the type 'T'. I think in this case you would
> still need the type operator to make it clear at parse
> time that 'T::T2' was a type.
[DR] Another simple point that we should agree on before moving forward:

To be a visible type, a type name must be one of the following:
1. built-in
2. a simple identifier that has been declared as a type with a typedef
or parameter type.
3. a simple identifier prefixed by a package scope.
4. The type operator preceded by the.
5. An interface port reference preceded by the keywords var or typedef
6. A Class scope reference preceded by the keywords var or typedef
> 
> Now the type operator has the side effect of converting
> a variable reference into a type. If you find that extremely
> objectionable, then it would require some new keyword like
> C++ to specify that 'T::T2' has to turn out to be a type.
> I was simply trying to avoid adding anymore new keywords
> to the language to handle this corner case.
> 
> 
> > -----Original Message-----
> > From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> > Sent: Monday, September 10, 2007 10:12 AM
> > To: Mark Hartoog
> > Cc: SV_EC List; SV_BC List
> > Subject: Re: Resolution of inherited type names
> >
> > Mark,
> >
> > First of all, "type T" in C++ is rather different in that it
> > is a specification that T denotes a type, it is NOT an
> > operator as such.  In your example, I am assuming that you
> > want "type(T2)"
> > to *conditionally* bind to T::T2 or type(int) depending on
> > whether T2 exists in T or not.  That is not at all what C++
> > does.  In C++, "type T"
> > means "treat the token T as a type" and is only needed once
> > in a context to deal with parsing ambiguities.  In your
> > approach you would need to use "type(T2)" on each occurrence
> > of T2 since "type" is an operator in SV and it is being used
> > not to indicate a static constraint (that T2 is a type) but
> > rather as a magic "defer the name lookup" operation.  T2
> > could still bind to either a type or a variable.
> >
> > You didn't address what a bare "T2" means -- is it illegal?
> > Does it mean the T2 in child?
> >
> > You've also argued that the special resolution only occurs in
> > methods.  How do you align that with your example here?  And
> > if you generalize your rules, how are you going to address
> > all the other problematic cases that I raised earlier?
> > Finally, types now appear to be completely different in your
> > approach -- you need some sort of explicit indication for
> > those but not for other things.
> >
> > Gord.
> >
> >
> > Mark Hartoog wrote:
> > > In C++ they introduced the typename keyword for cases were it was
> > > ambiguous if something was a type or not at parse time:
> > >
> > > template <class T>
> > >    class foo {
> > >       typename T::T2 x;
> > >    };
> > >
> > > The 'typename' keyword indicates that 'T::T2' must be a type.
> > >
> > > In System Verilog we do not need any new keywords, since we
already
> > > have the type operator for these cases:
> > >
> > >      module child #(type T = int);
> > >        int T2;
> > >        class C extends T;
> > >           type(T2) x;
> > >        endclass
> > >      endmodule
> > >
> > >> -----Original Message-----
> > >> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> > >> Sent: Friday, September 07, 2007 3:12 PM
> > >> To: SV_EC List; Mark Hartoog; SV_BC List
> > >> Subject: Resolution of inherited type names
> > >>
> > >> Mark, I think I raised this once a long time ago but I'll raise
it
> > >> again since I think we've both neglected to discuss this
scenario.
> > >>
> > >> Given your rules, I don't think you can have symmetric handling
of
> > >> type names versus member/property names when inheriting from an
> > >> opaque type.  Specifically, what rules would you apply
> > when dealing
> > >> with something like the following:
> > >>     module child #(type T = int);
> > >>       int T2;
> > >>       class C extends T;
> > >>          T2 x;
> > >>       endclass
> > >>     endmodule
> > >>
> > >> In order to be consistent with your approach elsewhere, would you
> > >> have to assume that "T2" is an inherited type and defer all of
the
> > >> handling until elaboration?  Is that even possible to parse in
> > >> general if you don't know whether T2 denotes a type or a
variable?
> > >>
> > >> I suspect that for inherited types in such a situation you
> > would have
> > >> to adopt an approach similar to mine, would you not?
> > >>
> > >> My suggested approach to solving such a scenario is
> > similar to what I
> > >> want to do in every case; require explicit referencing.  Here,
I'd
> > >> either be willing to allow something like "typedef T::T2 T2;"  or
> > >> "typedef super.T2 T2" to directly declare that "T2" is an
> > inherited
> > >> type.  In the long term, as I've suggested before, I'd like a
more
> > >> complete "specification" for "T" that would directly give the
> > >> assumptions about what T provides rather than working from
> > indirect
> > >> information in the body of C.
> > >>
> > >> Gord.
> > >> --
> > >>
> > --------------------------------------------------------------------
> > >> Gordon Vreugdenhil                                503-685-0808
> > >> Model Technology (Mentor Graphics)
gordonv@model.com
> > >>
> > >>
> >
> > --
> > --------------------------------------------------------------------
> > 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.