Re: Generic Instantiation as Subprogram Body? (Clarification)

Re: Generic Instantiation as Subprogram Body? (Clarification)

[Douglas N. Surber]

In <11225@platypus.uofs.uofs.edu> beidler@guinness.cs.uofs.edu (Jack Beidler) w
rites:

>Since "<=" is equivalent to "not >" and ">=" is equivalent to "not <"

  [  lots of stuff about how to implement relational operators (and
     some bad manners) deleted   ]

>  function "<" (l, r : U) return boolean is

>     begin
>        . . .

>     end "<":


First of all this is a toy example of a general problem.  The purpose of 
the posting was not to find out how to implement the relation operators,
but rather to explore the issues relating to using generic
instantiations as the implementations of subroutines declared in a
package spec.  I'm sorry my original posting was not sufficiently clear
in that aspect, so I'll clarify.

There does not appear to be any clean way to use an instance of a
generic as the implementation of a subroutine declared in a package spec
without putting the instantiation in the spec itself.  If for some
reason I wanted to implement a subroutine in that fashion, I wouldn't
want that to be part of the spec.  It is an implementation detail and
doesn't belong in the spec.  So, three questions:

1) Is there anyway to do this other than the kludges I listed in my
   original posting?

2) If not, what was the rationale behind this restriction?

3) Has this been fixed in Ada 9X?

Once again, I know lots of ways to implement relations, I am trying to
understand a glitch in the language definition that improperly couples
the specification of a package with its implementation.

Douglas Surber
Lockheed
Houston, TX

Re: Generic Instantiation as Subprogram Body? (Clarification)

[sun-barr!cs.utexas.edu!qt.cs.utexas.edu!news.Brown.EDU!noc.near.net!inmet]

In article <dnsurber.719094603@node_26400> 
dnsurber@lescsse.jsc.nasa.gov (Douglas N. Surber) writes:

> . . .
>There does not appear to be any clean way to use an instance of a
>generic as the implementation of a subroutine declared in a package spec
>without putting the instantiation in the spec itself.  If for some
>reason I wanted to implement a subroutine in that fashion, I wouldn't
>want that to be part of the spec.  It is an implementation detail and
>doesn't belong in the spec.  So, three questions:
>
>1) Is there anyway to do this other than the kludges I listed in my
>   original posting?
>
>2) If not, what was the rationale behind this restriction?
>
>3) Has this been fixed in Ada 9X?

Well, yes and no.  The current 9X proposals allow
the body of a subprogram to be a rename, including
a rename of an instantiation.

For readability and consistency reasons the body may not 
be an instantiation itself, since an instantiation
does not repeat the parameter profile, so correlating it
with the specification that it is implementing
is a potentially error-prone process in the presence of overloading.

Admittedly, allowing renames of instantiations but
not instantiations themselves seems a little arbitrary,
and we welcome comments on this issue if there are strong
feelings either way.

>Once again, I know lots of ways to implement relations, I am trying to
>understand a glitch in the language definition that improperly couples
>the specification of a package with its implementation.
>
>Douglas Surber
>Lockheed
>Houston, TX

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA

Re: Generic Instantiation as Subprogram Body? (Clarification)

[Douglas N. Surber]

In <1992Oct16.225115.11359@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tuck
er Taft) writes:

>For readability and consistency reasons the body may not 
>be an instantiation itself, since an instantiation
>does not repeat the parameter profile, so correlating it
>with the specification that it is implementing
>is a potentially error-prone process in the presence of overloading.

I guess I don't see why this is error prone, at least for the compiler.  It
certainly might be error prone for the human reader.  Given the name of the
generic subprogram and the generic actual parameters, the parameter profile
of the instance is known.  Admittedly the names of the formals could be
different, but the names of the formals are not used in overload resolution.
Thus it seems to me that the compiler should have no problem resolving any
overloading.  Of course I could have easily overlooked something.

It would certainly be error prone for the programmer.  But then so would
having to maintain two declarative items, the instantiation and the rename,
to properly implement a subprogram body.  This does seem arbitrary and it
more or less requires a kludge everytime a instantiation is used as a
subprogram body, but I guess it works and it is upward compatible.

I think I might prefer something like the following, although it is not
upward compatible.

Instead of having generic_instantiation as a possible alternative of
declarative_item, have new generic_subprogram_name [generic_actual_part]; as
an alternative for subprogram_body.  Ditto for functions and packages.  This
would eliminate the generic_instantiation as a non-terminal.  This seems
more natural to me.  As a reader of a program, I am not interested in the
fact that some package and some function are related in that they are both
generic instantiations, that doesn't tell me anything.  But I am interested
to see which method is used to specify a procedure, a complete body, an
instantiation, or a rename. (I would suggest the same sort of change for
renames.)  Each of these is a mechanism for specifying what happens when a
subprogram is invoked, at least this is how I think about it.

I don't have real strong feelings about this.  I think the current 9X
proposal is kludgy, but it is workable and upward compatible.  I would
prefer a cleaner solution, such as what I outlined above, but there would be
compatibility issues.  I'm glad I don't have to make the final decision.

Douglas Surber
Lockheed
Houston, TX