Change to obscure visibility rule in 9x

Change to obscure visibility rule in 9x

[Paul Graham]

Why did Ada 83 have this rule, and why did 9x eliminate it?

    8.3(16) Within the specification of a subprogram, every declaration
    with the same designator as the subprogram is hidden ... where
    hidden in this manner, a declaration is visible neither by selection
    nor directly.

Paul
--
Paul Graham 	graham@compass-da.com	Compass Design Automation, Inc.
(speaking only for myself)	"Cekoslovakyalilastiramadiklarimizdanmissiniz."

Re: Change to obscure visibility rule in 9x

[Robert I. Eachus]

    You seem to be right.  I just reread RM9X5.0, and the wording
changes seem to have lost this detail.  ("A declaration" is hidden,
not "all declarations."

    Now as to why.  During the declaration of a subprogram, its
parameter and result profile cannot be determined, in other
declarations similar things happen.  So to avoid requiring compilers
to do handsprings to determine whether or not a particular declaration
with the same name is hidden, they all are.

    But why "neither by selection nor directly"?  Because you can have
qualified names that name the current declaration or a component of
it.  How do you know whether or not the current unit is a (possible)
match of the qualified name?  Again, it is a nasty recursion, and
since it is also bad programming, the easiest rule is to make all the
problem cases illegal.

    There are a few cases which are considered stylisticly acceptable,
and the rules specifically allow such constructs as:

     package Float_IO is new Text_IO.Float_IO;
     procedure Reset renames Very_Long_Package_Name.Reset;

--

					Robert I. Eachus

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

Re: Change to obscure visibility rule in 9x

[Bob Duff]

In article <GRAHAM.94Oct18094458@clsi.clsi.com>,
Paul Graham <graham@clsi.COM> wrote:
>
>Why did Ada 83 have this rule, and why did 9x eliminate it?
>
>    8.3(16) Within the specification of a subprogram, every declaration
>    with the same designator as the subprogram is hidden ... where
>    hidden in this manner, a declaration is visible neither by selection
>    nor directly.

The reason for the Ada 83 rule was to simplify compilers.  In Ada 9X,
the same effect is achieved by 8.2(2);5.0, which is, we believe, simpler
still.  This is explained in AARM-8.2(2.a):

 2   {immediate scope (of a declaration)} The immediate scope of a declaration
 is a portion of the declarative region immediately enclosing the declaration.
 The immediate scope starts at the beginning of the declaration, except in the
 case of an overloadable declaration, in which case the immediate scope starts
 just after the place where the profile of the callable entity is determined
 (which is at the end of the _specification for the callable entity, or at the
 end of the generic_instantiation if an instance).

	 2.a   Reason:  The reason for making overloadable declarations with
	 profiles special is to simplify compilation:  until the compiler has
	 determined the profile, it doesn't know which other declarations are
	 homographs of this one, so it doesn't know which ones this one should
	 hide.  Without this rule, two passes over the _specification or
	 generic_instantiation would be required to resolve names that denote
	 things with the same name as this one.

The Ada 83 rule had the same effect, but required a special case in the
compiler -- the compiler must have a flag indicating that it's in the
process of analyzing a subprogram_spec, and must remember the name of
the subprogram.  In Ada 9X, this special case is eliminated.

An example is given in AARM-8.3(29.j):

    29.j   The scope of a subprogram does not start until after its profile.
	 Thus, the following is legal:

 29.k        X : constant Integer := 17;
	     procedure X(Y : in Integer := X);

    29.l   The body of the subprogram will probably be illegal, however, since
	 the constant X will be hidden by then.

    29.m   The rule is different for generic subprograms, since they are not
	 overloadable; the following is illegal:

 29.n        X : constant Integer := 17;
	     generic
	       Z : Integer := X; -- Illegal!
	     procedure X(Y : in Integer := X); -- Illegal!

    29.o   The constant X is hidden from direct visibility by the generic
	 declaration.

None of this makes much difference to anybody except a language lawyer.

- Bob
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: Change to obscure visibility rule in 9x

[Paul Graham]

>     29.j   The scope of a subprogram does not start until after its profile.
> 	 Thus, the following is legal:
> 
>  29.k        X : constant Integer := 17;
> 	     procedure X(Y : in Integer := X);


By my reading of Ada 83 RM 8.3(16), the above example should be illegal.
The rule says that every declaration with same designator ("X") as the
subprogram is hidden.  In particular, neither constant "X" or procedure "X"
is visible in the parameter list.

I agree that the 9x rules make example 29.k legal, by letting the name "X"
in the parameter list refer to the constant "X", but I don't see how it can
be legal in Ada 83.

> None of this makes much difference to anybody except a language lawyer.

I'm a VHDL language lawyer.  I figure I can get help from the Ada Bar
Association.

Paul
--
Paul Graham 	graham@compass-da.com	Compass Design Automation, Inc.
(speaking only for myself)	"Cekoslovakyalilastiramadiklarimizdanmissiniz."

Re: Change to obscure visibility rule in 9x

[Bob Duff]

In article <GRAHAM.94Oct20000151@canopus.clsi.com>,
Paul Graham <graham@clsi.COM> wrote:
>
>>     29.j   The scope of a subprogram does not start until after its profile.
>> 	 Thus, the following is legal:
>> 
>>  29.k        X : constant Integer := 17;
>> 	     procedure X(Y : in Integer := X);
>
>
>By my reading of Ada 83 RM 8.3(16), the above example should be illegal.
>The rule says that every declaration with same designator ("X") as the
>subprogram is hidden.  In particular, neither constant "X" or procedure "X"
>is visible in the parameter list.

That's right.  It was illegal in Ada 83, but legal in Ada 9X.  The above
quote comes from the Annotated Ada 9X Reference Manual, not the 83 RM.

>I agree that the 9x rules make example 29.k legal, by letting the name "X"
>in the parameter list refer to the constant "X", but I don't see how it can
>be legal in Ada 83.

Sorry if I mislead you.  I did *not* mean to say it was legal in Ada 83.
The original question was why was RM83-8.3(16) removed in Ada 9X, and I
was attempting to explain why.
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)

Re: Change to obscure visibility rule in 9x

[Simtel20 Transfer]

Bob Duff writes:
         2.a   Reason:  The reason for making overloadable declarations with
         profiles special is to simplify compilation:  until the compiler has
         determined the profile, it doesn't know which other declarations are
         homographs of this one, so it doesn't know which ones this one should
         hide.  Without this rule, two passes over the _specification or
         generic_instantiation would be required to resolve names that denote
         things with the same name as this one.

So the compiler has to look at a few hundred bytes of source code twice,
With today's 8MB and higher PCs that doesn't seem like any problem. It
seems like the one-pass goal should be deferred in favor of removing
rules, especially obscure ones.  I am not a compiler person so maybe
someone will say there is more to this than meets the eye.
sam harbaugh HARBAUGH@ROO.FIT.EDU

What's the difference between the new Denver airport and the White House?
You can land an airplane at the White House!

Re: Change to obscure visibility rule in 9x

[Bob Duff]

In article <INFO-ADA%94101904360935@vm1.nodak.edu>,
Simtel20 Transfer  <HARBAUGH@ROO.FIT.EDU> wrote:
>Bob Duff writes:
>         2.a   Reason:  The reason for making overloadable declarations with
>         profiles special is to simplify compilation:  until the compiler has
>         determined the profile, it doesn't know which other declarations are
>         homographs of this one, so it doesn't know which ones this one should
>         hide.  Without this rule, two passes over the _specification or
>         generic_instantiation would be required to resolve names that denote
>         things with the same name as this one.
>
>So the compiler has to look at a few hundred bytes of source code twice,
>With today's 8MB and higher PCs that doesn't seem like any problem.

The issue is not an efficiency issue, but a compiler complexity issue.
Forcing the compiler to have a first pass to figure out the type profile
of a given subprogram, then go back and decide which things are
homographs of the subprograms, and then make a second pass, doing
overload resolution on the default expressions, would be a large amount
of extra complexity in the compiler, just to handle something silly that
nobody would really want to write: "function F(X: Integer := F);".

Of course you're right that compilers have plenty of memory to do this
these days.  In fact they probably had plenty of memory in 1983 --
subprogram specs aren't that big.  But compiler complexity causes
compiler bugs -- a Bad Thing.

- Bob
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)