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: 8 Apr 93 18:10:45 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: Language lawyer needed
Message-ID: <EACHUS.93Apr8131045@dr_no.mitre.org>
List-Id: <comp.lang.ada>

In article <1993Apr7.183449.21551@sei.cmu.edu> dlehman@ajpo.sei.cmu.edu (Danfor
d Lehman) writes:


   Dan says:

  > 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. ~~~~~~~~~~~~~~~~~~~
	   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    But you don't need to modify that sentence, just include the
(misleadingly worded) previous sentence: "Where it is not visible by
selection, a visible declaration is said to be directly visible..."
As I said before perfectly correct, but misleading.  Paragraphs
8.3(6-13) have dealt with the case where visiblity is by selection,
8.3(14-16) deals with direct visibility.  The first sentence defines
directly visible to be visibile, but not visible by selection. 8.3(6)
says that at certain places, the only things that are visible are
thoses visible by selection.

  >     If you hold that variable declaration "x" is visible at all,
-- It isn't.
  > and obviously formal parameter specification "x" is also,
-- the same.
  > 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;

  It does.  If it didn't then the P's in P.P.P.P.P could all refer to
the same declaration.  (It is possible, but it is a pathological case:

 package Q is package P renames Q; end P;
 with Q; use Q; procedure P is pacakge R renames P.P.P.P.P;...
 
 see AI-187)

  > 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)!?)

  You read it wrong, if I use your reading the following would be legal:

  with Text_IO;
  package C is
    A: Integer;
    B: Integer := Text_IO.A; -- legal? Of course not!
  end C;

  If the preceding A was directly visible at the point following
"Text_IO.", this would be a very different--and much more
confusing--language.  So, where visibility by selection applies,
NOTHING is directly visible.



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...