From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 19 Oct 92 13:23:26 GMT
From: aio!dnsurber@eos.arc.nasa.gov  (Douglas N. Surber)
Subject: Re: Generic Instantiation as Subprogram Body? (Clarification)
Message-ID: <dnsurber.719501006@node_26400>
List-Id: <comp.lang.ada>

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