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: 7 Apr 93 22:34:49 GMT
From: agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-s
tate.edu!cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!dlehman@ucbvax.Be
rkeley.EDU  (Danford Lehman)
Subject: Re: Language lawyer needed
Message-ID: <1993Apr7.183449.21551@sei.cmu.edu>
List-Id: <comp.lang.ada>

Dave Collard writes:

> The 'x' in (2) does not refer to a variable -- it is part of a named
> parameter association and has nothing to do with the visibility of either
> the formal parameter 'x' or the 'x' declared in (1). ...

   Half right:  it has everything to do with the formal parameter, whose
specification is the only applicable visible (by selection) declaration
of 'x' at that point!

Tuck writes:

TT >  However, the declaration in (1) is not visible by selection at the
TT >  point at which x occurs in (2).
TT
TT This statement is false.  Which paragraph in RM 8.3 made you think
TT it was true?  Curious revisers of 8.3 want to know...

NOT (which flip-flops the "false" asserted above, of course).  Indeed, I'll
argue that at the (precise) point of 'x' in "Q(x=>0);", the variable "x"
declaration is not visible at all (and thus that 8.3(14) ought to read

	A declaration is directly visible within a certain part
	of its immediate scope [which] extends to the end of the
	immediate scope of the declaration, but excludes places where the
	declaration is hidden as explained below or where visibility is
	determined by selection as explained above. ~~~~~~~~~~~~~~~~~~~
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The relevant prg.s are:  8.3(6..12), 8.3(13), & 6.4(3).

  By 8.3(6..12), one finds no rules for visibility-by-selection that apply
  to the variable declaration "x".

  Which leaves only 8.3(14)'s "Finally, ..." as the one chance for vis-by-sel.
  But by 6.4(3) the only allowable name "at the point at which x occurs in (2)"
  is a name of a formal paramenter, right!?  So variable decl. "x" cannot be
  vis-by-sel at the point immediately between a subprogram call's left paren
  and compound delimiter '=>' in the parameter association.

   If you hold that variable declaration "x" is visible at all, and obviously
formal parameter specification "x" is also, don't you then contradict/conflict
with 8.3(4), which allows more than one meaning if and only if the identifier
is acceptable according to overloading rules (which don't apply in this case)?
Curious readers of 8.3 want to know, too!  (This is the reason for the tilde
underscored revision to 8.3 above.  Maybe 8.3(6) intends to say this, that
only one type of visibility is available at any given point; I read it to say
rather/simply that there are two types of visibility (and maybe at point P
each can be applied and yield ambiguity (in "package P is A : integer := 0;
B : integer := P.A; ... " this last A refers to the same decl. by either type
of visibility, and is thus not ambiguous)!?)

---Dan
------- *