From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!bu.edu!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.lang.ada
Subject: Re:  Expanded names and 4.1.3:18
Message-ID: <20600079@inmet>
Date: 12 Feb 91 02:15:00 GMT
Nf-ID: #N:inmet:20600079:000:1044
Nf-From: inmet.inmet.com!stt    Feb 11 21:15:00 1991
List-Id: <comp.lang.ada>


Re: Expanded names and 4.1.3:18

In response to a question by Scott Burson (Gyro@Reasoning.COM),
he wonders why subprograms and accept statements are singled out
by paragraphs 18 and 19 of section 4.1.3 dealing with expanded names.

The reason subprograms and accept statements are special is because
their identifier/operator symbol can overload, rather than hide
an outer occurence.  For the other constructs, the name
of the construct always hides an outer declaration of the same
identifer.

The combination of paragraph 18 and 19 implies that
if a prefix of a selected component can be interpreted
as the name of an enclosing subprogram/accept statement,
then it will be (no parameterless call will be considered),
and it is illegal if the name is overloaded by other
enclosing subprograms/accept statements.

As an editorial comment -- this is one of those rules
which was supposed to simplify overload resolution, but
in retrospect, may not have been worth the extra special case.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138