Re: [sv-ec] Mantis 1857 rationale - extern method types for parameterized classes

Mike,

It may be possible to deal with the issue with a set of rule
definitions although I am not convinced that it is.

There are some fairly nasty issues in SV regarding what
you know about types that are quite different than C++.
In particular, it is possible to have a type parameter
fundamentally change its nature and *not know* the nature
of the type at compile time.

For example, the class examples that I provided could be
inside a module:
    module M #(parameter type T = int);
        ...
    endmodule

At compile time, I do not know *anything* about "T".  It is
valid to change the type to a struct, an enum, a class, etc.
and not provide the type until elaboration time; in fact the
type might depend on bounds that depend on parameters that
participate in defparam or other override relationships.  This is
fundamentally different than C++ since in C++ one knows much
more about the actual type at compile time and most of the final
"type checking" is really resolved by mangled name link
resolution.

Once one composes the ability to use "::" on types
with the fact that package and class names are in different
name spaces, it isn't clear that one actually can always
correctly determine the type in the presence of extern
methods.  Perhaps one can by doing provisional imports
and only finalizing them once you determine whether a
function is in fact extern, but the complexity of doing
such resolution in the face of arbitrary types is very
troubling.

The complexities of implementation for parameterized
classes is very high already -- given the elaboration
model, it is arguably more difficult than C++ -- and I
am very hesitant to add any non-obvious or special
case name resolution rules to either the LRM or to
implementation since the likelihood of subtle issues
creeping in is simply too high.

I understand the "don't like new syntax" bias, but there
is also an "obviousness" consideration in terms of the
language design and in my opinion a syntax extension in this
area makes things much more obvious to the end user than
trying to come up with name resolution rules.

Gord.



Mike Mintz wrote:
> Francoise,
> 
> Sorry, I was sloppy in my wording. Of course we have to include any new 
> declarations. And true, they might just as easily cause name 
> collisions.  Yet these collisions do not seem to happen when the method 
> is defined inside the class. So some rule is at work to prevent a 
> collision (a related question is "How would one access the outer T?").
> 
> I am trying to propose an equivalent rule where template parameters take 
> precedence when defining a method body from that template, regardless of 
> whether the definition is inside the class declaration or external.
> 
>  > Using "::T" would be unique, and I would rather trying  to use 
> consistent rules in the LRM and not  inventing
>  > new ones. It is already too  complex.
> 
> Well, we could make "::" a global rule as a way to disambiguate multiple 
> typedefs, so it could be consistent.
> 
> In this case, the LRM is clearly broken.  I've been through very similar 
> issues with the development of the C++ language and feel strongly that 
> new syntax should be used only as a last resort. The fact that the code 
> works inside tells me that we can probably make a rule to make it work 
> externally.
> 
> Now, I will admit that I do not have a long history on  Verilog language 
> issues, so I will defer if the group prefers adding syntax to solve the 
> issue.
> 
> Take Care,
> Mike
> 
> 
> On 6/18/07, Francoise Martinolle < fm@cadence.com 
> <mailto:fm@cadence.com>> wrote:
>  >    
>  >  
>  >  
>  > Mike,
>  >  
>  > We cannot do either of your alternatives.  
>  > An extern method body must be able to refer  to
>  > declarations which appear between the "endclass" and  the beginning 
> of the body of the extern  method.
>  > Consequently you cannot say that the method body is as  if it were 
> defined inside the class.  Gordon
>  > provided some really good examples a few months ago  which make this 
> alternative not  possible.
>  >  
>  > Right now there is no provision for hierarchically  refer to a type 
> except in some cases (interface  types).
>  > Using "::T" would be unique, and I would rather trying  to use 
> consistent rules in the LRM and not  inventing
>  > new ones. It is already too  complex.
>  > I personally like the new prototype  syntax.
>  >  
>  > Francoise
>  >         '
>  >
>  >  
>  >    
>  >    ________________________________
>    From: owner-sv-ec@eda.org <mailto:owner-sv-ec@eda.org>    [mailto: 
> owner-sv-ec@eda.org <mailto:owner-sv-ec@eda.org>] On Behalf Of Mike Mintz
>  > Sent:    Monday, June 18, 2007 11:06 AM
>  > To: Jonathan Bromley
>  > Cc:    Gordon Vreugdenhil; SV_EC List
>  > Subject: Re: [sv-ec] Mantis 1857    rationale - extern method types 
> for parameterized classes
>  >
>  >
>  >    
>  > Gord,
>  >
>  > >In the first case, the name "T" is visible in the    scope
>  > of the definition (i.e. the "typedef bit T") so that is
>  > the "T"    that will be selected.  Clearly that is incorrect.
>  >
>  >
>  > This is    the incorrect behavior. Can we say that a scoped method 
> body (such as this) is    within the scope of the declaration (for name 
> resolution purposes) ?
>  >
>  > If    not, what about saying that the unchanged code means the 
> templated param, and    that, if the bit T is wanted, it needs to have a 
> "::" to say the outer scope?    
>  >
>  > My feeling is that a rule is better than syntax.
>  >
>  > Take    Care,
>  > Mike
>  >
>  >    
>  > On 6/18/07, Jonathan    Bromley <     jonathan.bromley@doulos.com 
> <mailto:jonathan.bromley@doulos.com>> wrote:  
>  > > Gord,
>  > >
>  > > I      absolutely concur with the motivation and solution.  As long 
> as      
>  > > you and all the heavy-duty compiler folk are happy that the
>  > > solution      is bombproof, I'm happy.
>  > > --
>  > > Jonathan
>  > >
>  > >
>  > > -- This message has      been scanned for viruses anddangerous 
> content by MailScanner, and isbelieved      to be clean.
>  > >
>  > >
>  >
>  >
>  > --
>  > 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.