Re: Language lawyer needed

[stt@spock.camb.inmet.com (Tucker Taft)]

In article <1993Apr1.215753.3147@oracorp.com> 
  davidg@oracorp.com (David Guaspari) writes:

>Here's a question for language lawyers.

Oh boy.

>Consider the following pathological program:
>
>   procedure Q(x : integer) is  
>   begin
>     declare
>       x : integer;   -- (1)
>     begin
>       Q(x => 0);     -- (2)
>     end;
>   end Q;
>
>My question concerns the legality of Q (forgetting about the fact that
>its execution won't terminate).  One way to apply chapter 8 in the
>reference manual goes as follows:
>
>  The declaration of x in (1) hides the declaration of x as a formal
>  parameter of Q.

"Hide" in this context only means "hide from direct visibility."
It is still "visible" since it is visible by selection (e.g. "Q.x" can
be used as a way to name the formal parameter "x").
See RM 8.3(14):
   . . .  A declaration is directly visible within a certain part of its
   immediate scope ... but excludes places where the declaration
   is hidden as explained below.

In other words, normal "hiding" only affects direct visibility.
However, just to confuse you, there are kinds of hiding that affect
visibility by selection:

   1) Inside a subprogram specification, all declarations with the
      same simple-name as that of the subprogram are hidden from *all*
      visibility (RM 8.3(16)).

   2) Within the scope of an explicit declaration of a derivable subprogram
      any implicit declaration for a derived subprogram with the same
      profile declared immediately in the same decl. region is
      hidden from all visibility (RM 8.3(17)).

These two are special cases.  The normal hiding caused by a declaration
in an inner declarative region (like your example) only affects
direct visibility.  By the way, we are getting rid of special case (1)
in Ada 9X, since the rule is generally surprising and annoying whenever 
it has any effect.  [If you are interested, see RM9X-8.2(2);2.0, 
where it is specified that the scope of an overloadable 
declaration doesn't start until after its profile (aka formal part, if any), 
thereby eliminating the problem that the rule of RM 8.3(16) (special case (1)
above) was trying to solve.  The problem was that before the profile,
it is not clear with which other declarations the new declaration would
be a homograph, making it difficult to enforce RM 8.3(17) (special
case (2) above).]

>  Therefore, by the visibility rules, the occurrence of x in (2) has
>  exactly one possible meaning, namely that given by the declaration
>  in (1). 

No way, Jose'.  The identifier preceding "=>" in a parameter association
does not use "direct visibility" but rather "visibility by selection"
(see RM 8.3(6,11)).  The declaration at (1) does not hide
the declaration of the formal parameter X for the purposes of
visibility by selection.

>  However, the declaration in (1) is not visible by selection at the
>  point at which x occurs in (2).

This statement is false.  Which paragraph in RM 8.3 made you think
it was true?  Curious revisers of 8.3 want to know...

>  Therefore the call in (2) is illegal.

No, the call in (2) is legal.

>One the other hand, at least one compiler (Telesoft) thinks that Q is
>legal, an outcome that seems a reasonable enough outcome to common
>sense untutored by the reference manual.  So, what *is* the right
>answer, and how do we get it from the RM?

Hopefully the above references explain the rule.
By the way, in RM9X we use "selector_name" wherever visibility
by selection is relevant, and "direct_name" wherever direct visibility
is relevant.  In particular, the identifier preceding "=>" is
a selector_name, not a direct_name.  Hopefully this change will make 
the BNF more suggestive of the semantics.

>- David Guaspari
>  davidg@oracorp.com

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