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

Arturo,

As you note, the behavior of "C::T" for a parameterized class
type is ambiguous right now.

I don't like the approach that I think you are taking in that
you end up having:
     C::T
mean two different things depending on the context of use.  Within
a parameterized class (or an extern method) it would be just be scope
identification whereas in other contexts it would mean "T within the
default specialization".  Allowing that form to ever have two meanings
is going to be deeply confusing to users.

I think that a modification of your suggestion would probably be Ok --
C::T is scope disambiguation but may ONLY be used in the context of
a parameterized class (or its external methods).  In any other context
the form C#()::T would be required.

We then end up with two options:
   1) C::T is pure scope naming and can only be used within the
      parameterized class (or its extern methods)
   2) C::T always means "T within the default specialization"

Either choice introduces a stronger consistency.  I had been
following (2) but (1) also works.

I've always been unhappy about use of the base parameterized class
name as a default specialization but was willing to live with that
primarily due to the "mailbox" class.  I think that this entire
discussion has revolved around the reason why I didn't like the
implied specialization -- it confuses an abstract name (the
parameterized class "factory" name) and a real type name.

So, in the interest of reducing confusion, I would be willing
to go along with my modified version in (1).  I would oppose
having C::T mean two different things in a context dependent
manner.

Note that if we go this route (and probably even if we don't),
we need to clarify the statement:
    The out-of-block method declaration must match the prototype
    declaration exactly; the only syntactical difference is that
    the method name is preceded by the class name and the class
    scope resolution operator ::.
Clearly that isn't true with your examples since other names
are also prefixed by the parameterized class name.

In terms of the syntax for the block form, I don't
like "use" all that much.  Someone had mentioned "within"
at the last meeting and that makes more sense to me than
"use", particularly since other languages have "use" mean
"import".

Your example also skips the redeclaration of that parameterized
class arguments which my proposal requires.  I was (and still am)
willing to make that optional, but others in the user base felt
more strongly that the redeclaration of the parameters should
be required.

Gord



Arturo Salz wrote:
> In the last meeting, I agreed to write an informal proposal for Mantis 
> item 1857.
> 
>  
> 
> To recap, the problem is how should users specify the function return 
> type in an out-of-body implementation of a method whose return type is a 
> class parameter. As I mentioned in the meeting, I prefer to address the 
> issue in a more narrow manner than Gord’s last proposal.
> 
>  
> 
> This proposal is based on the observation that there already exists 
> syntax that naturally designates a class parameter when used in the 
> prototype of an out-of-body method implementation (and in particular the 
> return type). The syntactical construct is:
> 
> class_identifier*::*parameter_identifier
> 
>  
> 
> At present, the LRM is ambiguous as to the meaning of this syntactical 
> construct when used to specify the return type of a method 
> implementation outside the body of the class declaration. In that 
> context, two possible meanings can be associated with this construct: 
> (1) the name of the (unspecialized) parameter, or (2) the default 
> specialization of the parameter. By explicitly defining this syntax to 
> designate the (unspecialized) parameter when used in the prototype of an 
> out-of-body method implementation we solve two problems: We resolve the 
> ambiguity and we provide a natural syntax to specify the class parameter 
> outside the class declaration.
> 
>  
> 
> I believe this interpretation makes sense because in the context of an 
> out-of-body method implementation, designating the (unspecialized) 
> parameter rather than the default specialization is more much more 
> common and useful. For those rare cases in which users wish to designate 
> the default specialization in the method implementation, they can do so 
> via the more explicit and unambiguous syntax. Hence, assuming a class C 
> parameterized by parameter P, this proposal defines the following 
> interpretations within the prototype of an out of body method:
> 
>  
> 
>             C::P                  =>  The (unspecialized) parameter P of 
> class C
> 
>             C#()::P              =>  The parameter P of the default 
> specialization of class C
> 
>             C#(T)::P            =>  The parameter P of the 
> specialization to “T” of class C
> 
>  
> 
> Note that the last two have the exact same meaning in any other context, 
> the only distinction is for this context is the first form. Note that 
> Gord’s proposal also provides for a similar irregularity. The benefit of 
> this proposal is that it is backward compatible.
> 
>  
> 
> Example:
> 
>  
> 
> class C#(type T = int);             // class declaration:
> 
>    extern function T f(T x);
> 
>    extern function T g(bit b);
> 
> endclass
> 
>  
> 
> // Out-of-body implementations:
> 
>  
> 
> function C::T C::f(T x);
> 
>     ...
> 
> endfunction
> 
>  
> 
> function C::T C::f(bit b);
> 
>     ...
> 
> endfunction
> 
>  
> 
> Note that under the proposed rules, the following definition would be 
> equivalent (the proposal is to treat the prototype of a method 
> implementation differently):
> 
>  
> 
> function C::T C::f(_C::T_ x);
> 
>     ...
> 
> endfunction
> 
>  
> 
> IMHO, the above definition completely addresses the original problem in 
> an intuitive manner. This can be made clear in the LRM by  adding a 
> sentence that states: Any reference to the parameterized class name in 
> any other type context shall denote the default specialization. 
> 
> Putting the above interpretation aside, I discovered that there is merit 
> to Gord’s idea of giving users the ability to specify a class scope for 
> the purpose of out-of-body method implementations. However, using the 
> extern keyword for that purpose was very controversial, so I came up 
> with the following alternate syntax:
> 
>  
> 
> use class class_identifier;
> 
>     // method implementations here
> 
> endclass
> 
>  
> 
> For example, using the previous example, we can declare both methods 
> using the following:
> 
>  
> 
> use class C;
> 
>     function T f(T x);
> 
>         ...
> 
>     Endfunction
> 
>  
> 
>     function T g(bit b);
> 
>         ...
> 
>     endfunction
> 
> endclass
> 
>  
> 
> Note that this syntax des not add any new keywords (the “use” keyword is 
> part of the configuration syntax). I discussed this with several users 
> and they found that this syntax fairly intuitive. Therefore, my proposal 
> is to allow both syntactical forms: the special definition of C::T in 
> the prototype of an out-of-body method prototype, and the new syntax 
> that re-uses the “use class” keywords to re-introduce the class scope 
> for the purposes of implementing the out-of-body methods.
> 
>  
> 
>             Arturo
> 
>  
> 
> PS – I will not be able to attend next Monday’s meeting.
> 
>  
> 

-- 
--------------------------------------------------------------------
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.