Language lawyer needed

Language lawyer needed

[David Guaspari]

Here's a question for language lawyers.

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.

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

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

  Therefore the call in (2) is illegal.

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?

- David Guaspari
  davidg@oracorp.com

Re: Language lawyer needed

[Dave Collard x7468]

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

>Here's a question for language lawyers.

>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.

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

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

>  Therefore the call in (2) is illegal.

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).  Q is visible at (2)
with the correct parameter and result type profile -- that is
the name 'x' is indeed a formal parameter of Q and the actual 
0 matches the integer type of that parameter.


--Thor
dlc@ddsdx2.jhuapl.edu

Re: Language lawyer needed

[Mike Berman]

Arf! Sorry about that last posting - I just discovered that my
newsreader chokes on reposted dead.articles.

Here's the relevant part:

davidg@oracorp.com (David Guaspari) writes:
| Here's a question for language lawyers.

	Hopefully an Ada instructor will do.

| 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.
| 
|   Therefore, by the visibility rules, the occurrence of x in (2) has
|   exactly one possible meaning, namely that given by the declaration
|   in (1). 

|   Therefore the call in (2) is illegal.

Visibility is not defined for just identifiers. The section of the LRM
to which you are referring describes rules "for each identifier and at
each place in the text." Like the real estate biz, the important thing
in your example is location, location, location. The occurrence of
x in (2) clearly can only be a subprogram parameter for procedure Q.

-- 
Mike Berman
University of Maryland, Baltimore County	Fastrak Training, Inc.
berman@umbc.edu					(301)924-0050

Re: Language lawyer needed

[Wes Groleau X7574]

Hey, everyone, please don't flame the poor guy!

<name withheld to prevent forest fires> writes:
>Here's a question for language lawyers.
>
>Consider the following pathological program:
>
>   procedure Q(x : integer) is  
>   begin
>     declare
>       x : integer;   -- (1)
>     begin
>       Q(x => 0);     -- (2)
>     end;
>   end Q;
>

The "x" in (2) is NOT a variable; it is there to tell the compiler (which
knows anyway) WHICH of the parameters of Q needs to get the value zero.
Study up in all your Ada books, including the LRM, about named associations,
if you really want to know about this.

On the other hand, if you're just nit-picking to make Ada look bad, it didn't
work: we adults can tell the difference between "bad" and "not perfect"

Re: Language lawyer needed

[Robert I. Eachus]

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

  > 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.

  So the name of the parameter is no longer directly visible, but is
visible only by selection.  Okay.

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

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

  >   Therefore the call in (2) is illegal.

  Nope.  8.3(6 & 11) say:

  Visibility is either by selection or direct.  A declaration is
visible by selection at places that are defined as follows.

  (e)  For a parameter specification of a given subprogram declaration
or entry declaration:  at the place of the formal parameter (before
the compound delimiter =>) in a named parameter association of a
corresponding subprogram or entry call.

   So not only is the parameter X visible by selection, it is the only
X visible so there is no problem.  The terminology here is a little
misleading.  The or in 8.3(6) is not a choice, it really stands for
"there are locations where visibility is determined using the rules
for selection, other rules apply everywhere else."  The first sentence
of paragraph 8.3(14) is the offender here, it is technically correct
but misleading: "Where it is not visible by selection, a visible
declaration is said to be _directly_ visible."  It says that
visibility by selection preempts direct visibility, but seems to say
that it applies on a name by name basis, rather than to the process of
visibility as a whole.



--

					Robert I. Eachus

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

Re: Language lawyer needed

[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

Re: Language lawyer needed

[Rich Messenger]

davidg@oracorp.com (David Guaspari) writes:

>Here's a question for language lawyers.

>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: [omitted]

I'm no language lawyer, but I looked this up in the LRM index and found
the following rule which explains why this works:

    8.3.6: Visibility is either by selection or direct. A
    declaration is visible by selection at places that are defined
    as follows:
    ...
    (e) For a parameter specification of a given subprogram
    specification or entry declaration: at the place of the formal
    parameter (before the compound delimiter =>) in a named
    parameter association of a corresponding subprogram or entry
    call.

In other words, in the named parameter association "x" is considered to
be selected in the same sense that dot notation can be used to select a
declaration from the visible part of a package declaration.
-- 
     _ __
    ' )  )      /                      Rich Messenger
     /--' o _. /_                      rich@wilbur.coyote.trw.com
    /  \_(_(__/ /_                     ...!{uunet,cit-vax,trwrb}!wiley!rich

Re: Language lawyer needed

[agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-s]

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
------- *

Re: Language lawyer needed

[Robert I. Eachus]

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...

Re: Language lawyer needed

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!noc.n]

In article <1993Apr2.193753.22289@inmet.camb.inmet.com> 
 stt@spock.camb.inmet.com (Tucker Taft) writes:

>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;
>>
>> . . .
>>  However, the declaration in (1) is not visible by selection at the
>>  point at which x occurs in (2).
>
>This statement is false.  

Oops; I misread David's original sentence -- it is in fact
true.  The declaration in (1) is not visible by selection preceding
the "=>" in (2).  (My misreading had replaced "the declaration in (1)"
with "the first declaration of x".)

The basic confusion illustrated by David's message
comes from the word "hide" which does *not* imply the 
earlier declaration is "invisible" 
but rather simply not *directly* visible (I guess it is 
"indirectly visible" ;-).  

On the other hand, "hide from *all* visibility" does 
mean the declaration is visible neither directly nor by selection.  
This more "obscure" (so to speak) kind of hiding only happens in a 
few cases (within a subprogram specification, and for implicit
declarations overridden by explicit declarations).
It is probably best to just ignore these obscure cases when
trying to build an "intuition" for what the word "hide" means
in Ada.  

(Perhaps a better word for "hide" might be the verb "obscure" ;-)

>>- David Guaspari
>>  davidg@oracorp.com
>
>S. Tucker Taft      stt@inmet.com
>Ada 9X Mapping/Revision Team
>Intermetrics, Inc.
>Cambridge, MA  02138

-S. T. Taft