From Newsgroup: comp.lang.ada

--=-=-=
Content-Type: text/plain

I've been reading the Annotated Ada Reference Manual for Ada 95, with
the corrigendum (ISO/IEC 8652:1995(E) with COR.1:2000). In 8.2(11.a) it
states:

"Ramification: the rule for immediate scope implies the following: [...]

The immediate scope of a declaration immediately within the body of a
library unit does not include any child of that library unit.

This is needed to prevent children from looking inside their parent's
body. The children are in the declarative region of the parent, and they
might be after the parent's body. Therefore, the scope of a declaration
that occurs immediately within the body might include some children."

While all indications are that this corresponds with the intent of the standard, I cannot piece together which normative portions of the
standard interact to actually specify this. The wording suggests that
this is implied by "the rule for immediate scope", but immediate scope
is defined back at 8.2(2) on the previous page, so I don't know why this annotation appears here. Nothing about 8.2(2) or its exceptions 8.2(3)
and 8.2(4) suggests that the immediate scope of a declaration
immediately within the body of a library unit does not include any child
of that library unit, or at least their private parts.

8.2(2) reads:

"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). The immediate
scope extends to the end of the declarative region, with the following exceptions:

- The immediate scope of a library_item includes only its semantic
dependents.

- The immediate scope of a declaration in the private part of a library
unit does not include the visible part of any public descendant of
that library unit."

Due to the syntax rules, no declaration immediately within the body of a library unit can be a library_item, so the first exception cannot apply
to the hypothetical declaration under consideration.

Whether a declaration immediately within the body of a library unit is considered to be in its private part or not, the second exception cannot prevent its immediate scope from including the private parts or bodies
of public child units, nor can it prevent its immediate scope from
including private child units in their entirety.

The only other index entry for "immediate scope" is 8.2(11), which
reads:

"The immediate scope of a declaration is also the immediate scope of the
entity or view declared by the declaration. Similarly, the scope of a declaration is also the scope of the entity or view declared by the declaration."

It is not immediately apparent to me how defining immediate scope for
views and entities implies what 8.2(11.g) claims. I searched the entire standard for every occurrence of "immediate scope" and couldn't find a
usage that seemed relevant.

The standard has several places that informally claim that declarations
within a body are only visible within it, such as 7.2(1):

"In contrast to the entities declared in the visible part of a package,
the entities declared in the package_body are visible only within the package_body itself. As a consequence, a package with a package_body can
be used for the construction of a group of related subprograms in which
the logical operations available to clients are clearly isolated from
the internal entities."

While this introductory text is strictly speaking normative, due to
neither being a note nor part of an example, the AARM has marked it with
square brackets, indicating "text that is logically redundant".
Additionally, it only applies to package bodies, not library unit bodies
in general.

Likewise, 7.2(7) says:

"A variable declared in the body of a package is only visible within
this body [...]"

but this is placed with the NOTES for 7.2, and is therefore
non-normative.

On top of all of this, the wording of 8.2(11.g-11.h) is itself
confusing. The annotation is a "ramification", and it describes its
claim as an implication of the rule for immediate scope, but it also
says of its claimed property "this is needed to prevent children from
looking inside their parent's body". It goes on to say that "the scope
of a declaration that occurs immediately within the body might include
some children", which seems to contradict claims about the opaqueness of package bodies mentioned earlier.

This would make a little more sense if instead of being a "ramification" annotation it were a "to be honest" annotation; if it were asserting
extra rules, I could understand its "might include some children" to
mean "if we hadn't specified this, it would have this consequence".

I'm starting out by reading the specification for Ada 95 because it's
much smaller than later versions and seems like a good place to start,
but I also (admittedly briefly) skimmed section 8 of the Ada 2022 AARM
and didn't notice anything that would change the rules for immediate
scope.

I get the impression that I am missing something that should be fairly
obvious, but 8.2(11.g-11.h) itself rules out anything I can think of: it asserts that something about the definition of immediate scope itself
prevents child library units from looking into parent bodies, but I
can't find it. It's almost as if there's some extra exception to
immediate scope that was simply left out on accident, but I find it hard
to believe that such an omission could have made it to 2022 uncorrected.

I'll keep reading over the standard trying to find an answer, but in the meantime I'd like to ask the venerable experts of comp.lang.ada: what am
I missing?

(P.S: if while answering this you happen to come across a proof of
8.2(11.f), I'd be interested in that too)

- Ulf Herrman

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQHIBAEBCAAyFiEEn6BUn0yca1D9JsMa1lV76sJM9mgFAmq8C10UHHN0cmluZXNz QHRpbGRlLmNsdWIACgkQ1lV76sJM9mh2Xwv+Ikx9M7YODgs8fZf3GPBlDPpWtmQn jqBbHDq0NUpmhUtJ9jj4URRc9LFT0G1KeaAdNZIIINbEq+2fZtKYjsR4wprsBOrZ FU5Y14iNWB+TlxE5/ezIkvwNKxn8+4A67pluvaVV0gDUS3BeMmx8PoQWJksb8UOn bwr3ZUDMwud2NlD+h08yFXHZ73XNkeRHG5VgpD+Lu589H0+G3of2SX2XRg2m1I+1 UkFPklBCIkLQtjb9VnF4meZpDZy4jlzs/s2sDSgK1nhMpm14noE9TOSdci9zdOsf JolBjUJTuuNYSGzqne0xf/xmFBQWtn2N7T/8geOTVHDVuE+GzRUVb1adbx/lIjmW e2mLjHtxxW/h/6XLW/oHkZwL2nV9kFx5ZeG4EX1UZZ/dcmFXFM26ZFVdWcCCXN2c Z01zDxhzoZfM+QSYoA+trZU62gR/YzNUOzo2wPyGpDe5KeOlD/uraraePXMarKs1 RaiRB/FCx60PJ3lPKFcIHHwl6Zm4RbVJpMmQ
=5N2H
-----END PGP SIGNATURE-----
--=-=-=--
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On 2026-09-29 21:02, [email protected] wrote:

I've been reading the Annotated Ada Reference Manual for Ada 95, with
the corrigendum (ISO/IEC 8652:1995(E) with COR.1:2000). In 8.2(11.a) it states:

c.l.a is unfortunately dead. You should try to post rather here:

https://forum.ada-lang.io/

As for your question I don't quite understand the problem. Nothing can
depend on the body, except separate bodies of.

P.S. I too wonder the language of RM, specifically its conflation of
stated goals with syntactic means, rather than plainly saying: "we want
this, informally, therefore this, formally."

Note also that Ada 2022 RM made things far worse. Ada 95 RM is a shining beacon of clarity in comparison.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

Dmitry A. Kazakov <[email protected]> wrote: |-------------------------------------------------------------------------| |"On 2026-09-29 21:02, [email protected] wrote: |
| |

I've been reading the Annotated Ada Reference Manual for Ada 95, with |
the corrigendum (ISO/IEC 8652:1995(E) with COR.1:2000). In 8.2(11.a) it| states:" |

|-------------------------------------------------------------------------|

Paganini.BOFH.team does not have this thread's original post (from
Eternal September). Pasdenom.info does have it.

|-------------------------------------------------------------------------| |"[. . .] You should try to post rather here: |
| |
| https://forum.ada-lang.io/ |
| |
|[. . .]" | |-------------------------------------------------------------------------|

This website demands a bad webbrowser!

(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

--=-=-=
Content-Type: text/plain

"Dmitry A. Kazakov" <[email protected]> writes:

On 2026-09-29 21:02, [email protected] wrote:

I've been reading the Annotated Ada Reference Manual for Ada 95, with
the corrigendum (ISO/IEC 8652:1995(E) with COR.1:2000). In 8.2(11.a) it
states:

c.l.a is unfortunately dead. You should try to post rather here:

https://forum.ada-lang.io/

So long as we are communicating on it, it is live enough for my
purposes. But thanks for the link, I'll consider cross-posting there
also.

As for your question I don't quite understand the problem. Nothing can
depend on the body, except separate bodies of.

(tl;dr: semantic dependence is only required in order for a compilation
unit to be included by the immediate scope of a library_item, not the
immediate scope of any declarations contained within it. Long version
follows.)

Right, I understand this to be the intent. The problem is twofold:

1. I haven't been able to find anywhere in the standard that actually
spells out formally, in normative text, that this is the case, and by
what mechanism. The annotation at 8.2(11.g) claims one thing, seems
to show that the rules of the language suggest something else, and
then offers no explanation for why its original claim is correct. To
put it bluntly: I don't understand 8.2(11.g). I understand what it is
claiming, but I have no idea what normative text can be interpreted
to support that claim.

Not knowing the mechanism means that I don't know how to structure my
programs for processing Ada in a way that can be adapted more or less
naturally to newer revisions of the language. It also makes it harder
to ensure that my programs are conformant.

2. The fact that I don't understand 8.2(11.g) suggests that I am missing
some crucial detail that the authors of AARM95 clearly thought should
be obvious. But I have no idea what it is, and this bugs me. The
wording suggests that it should be related to the definition of
immediate scope, and I have re-read it over and over, but still
cannot see how this prevents the immediate scope of a declaration
immediately within a body library unit from including any child
library units.

For example:

package P is
pragma Elaborate_Body;
end P;

package body P is
X : Integer := 1;
end P;

package P.C is
private
X2 : Integer := X; -- (1)
end P.C;

The RM is clear that the declaration of P.C occurs immediately within
the declarative region of the declaration of P, and that the declaration
of P.X occurs immediately within the declarative region of the
declaration of P, and that, barring the exceptions outlined in 8.2(3)
and 8.2(4), the immediate scope of P.X extends from the beginning of its declaration to the end of the declarative region immediately enclosing
it.

8.2(3) reads: "The immediate scope of a library_item includes only its
semantic dependents."

8.2(3) cannot affect the immediate scope of P.X, because P.X is not a library_item, and no mechanism is given for the immediate scope of P to restrict the immediate scope of P.X AFAIK. I understand that there is no
way to have a semantic dependency on the body of P aside from subunits,
but the rules do not require that the body of P be semantically depended
on by a compilation unit in order for X to include that place in its
immediate scope; that would only be necessary for a library_item to
include that place in its immediate scope.

Is there some rule somewhere that enforces the hierarchical nature of
immediate scopes? I could perhaps understand if this rule was intended
to mean "the immediate scope of a library_item and any declaration
occurring inside it includes only the semantic dependents of that library_item", where "includes only" is interpreted to mean "excludes everything but".

(presumably a compilation unit is a semantic dependent of itself?)

8.2(4) reads: "The immediate scope of a declaration in the private part
of a library unit does not include the visible part of any public
descendant of that library unit."

8.2(4) cannot affect whether the immediate scope of P.X contains (1),
because (1) is not in the visible part of any public descendant of
P. It's also not clear whether P.X counts as being in the "private
part", since it's not in the declaration of P.

Therefore the immediate scope of P.X contains (1). None of the rules for
hiding from all visibility or direct visibility apply, so P.X is
directly visible at (1).

This is of course not the intent of the authors, or of the implementers,
or of anyone, as far as I know, but as far as I can tell that's what the
rules say. Hopefully someone can point out something I've missed and I
will gladly kick myself for missing it for so long.

P.S. I too wonder the language of RM, specifically its conflation of stated goals with syntactic means, rather than plainly saying: "we want this, informally, therefore this, formally."

Note also that Ada 2022 RM made things far worse. Ada 95 RM is a
shining beacon of clarity in comparison.

Then it's a good thing I'm starting with Ada 95. One step at a time,
someday I shall attain the heights of mind-reading necessary to
understand the Ada 2022 RM.

Thanks,

- Ulf Herrman

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQHIBAEBCAAyFiEEn6BUn0yca1D9JsMa1lV76sJM9mgFAmrAipMUHHN0cmluZXNz QHRpbGRlLmNsdWIACgkQ1lV76sJM9mgACQwAr7V2gz7hHDUqe0qYcHBCX/BpPc3u jo48CwopIdrroa1KN9cbK7JkU/vNV7fCeY4j2XOPGdRRCbKr9qu4o8nMu9podqyL 91U3ayOmEUuvHNftoLX/3aAsIouhP7cUIM7jjgLJCQU1Zkyo/+mHpTZm3VJ9vVfv kCVl6wEmvdlmAkZdiJaMFjZHZ+ek9h6t5zSYV5pDVHyfMzEoOXuGvPMh9OC7eDNX rCvK/VG0LuamRZWxHJxffosN0jLOCrDfQHzKQXQFDh4PMnq6TYmucrTecD+Qso3J m+4+MOnZFIknpkBqxacu7B5X1qFIgqbLKM3ci29MDH88C+4h09hzZHl37siu2Zr6 8Oi/cqzR4Vc31JWbgNE24RprTJ7dTZmgFAf7eOxuIC/KR0D36X0mAJ6lgrbBAbJ2 09HANmKNyIGWsHlT6RfibrsurJzmRvi2tG8xSgjqBX991t2hK+Go3yDBu2n3KDor Jv8Vkut9XeMoSay7x4yOK0hJeh90fkyyiGgw
=k9GR
-----END PGP SIGNATURE-----
--=-=-=--
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

On 2026-10-03 06:54, [email protected] wrote:

"Dmitry A. Kazakov" <[email protected]> writes:

On 2026-09-29 21:02, [email protected] wrote:

I've been reading the Annotated Ada Reference Manual for Ada 95, with
the corrigendum (ISO/IEC 8652:1995(E) with COR.1:2000). In 8.2(11.a) it
states:

c.l.a is unfortunately dead. You should try to post rather here:

https://forum.ada-lang.io/

So long as we are communicating on it, it is live enough for my
purposes. But thanks for the link, I'll consider cross-posting there
also.

You should, if you want a response from a real language lawyer. I am not.

(tl;dr: semantic dependence is only required in order for a compilation
unit to be included by the immediate scope of a library_item, not the immediate scope of any declarations contained within it. Long version follows.)

Right, I understand this to be the intent. The problem is twofold:

1. I haven't been able to find anywhere in the standard that actually
spells out formally, in normative text, that this is the case, and by
what mechanism.

It is the immediate scope 8.2(1), which is a purely syntactic thing. It
starts after the defining identifier appearance and ends after the
closing element like "end." Some juggling with visibility is added on
top to prevent stuff like

X : Integer := X + 1;

For example:

package P is
pragma Elaborate_Body;
end P;

package body P is
X : Integer := 1;
end P;

package P.C is
private
X2 : Integer := X; -- (1)
end P.C;

The RM is clear that the declaration of P.C occurs immediately within
the declarative region of the declaration of P, and that the declaration
of P.X occurs immediately within the declarative region of the
declaration of P

I don't think so. P.X is declared in the declarative region of the body
of P, not in the declarative region of P. The scope of P.X ends with the
body of P.

Note also that Ada 2022 RM made things far worse. Ada 95 RM is a
shining beacon of clarity in comparison.

Then it's a good thing I'm starting with Ada 95. One step at a time,
someday I shall attain the heights of mind-reading necessary to
understand the Ada 2022 RM.

Well, 8.1 in Ada 2022 RM is three times longer than in Ada 95 RM!

P.S. If you decide to visit https://forum.ada-lang.io you will find a
lot of my postings about funny and incredible visibility stuff in Ada.
There exist totally illogical and confusing cases, which are shrugged
off and worked around in daily programming.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada


Cóilín Nioclásín Glostéir <[email protected]> writes:

Paganini.BOFH.team does not have this thread's original post (from
Eternal September).

Probably was filtered out because of PGP signature.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

All of this is made super-explicit in 7.2(1) but a language lawyer
enjoys delving into details :)

[email protected] writes:

For example:

package P is
pragma Elaborate_Body;
end P;

package body P is
X : Integer := 1;
end P;

Reading 8.1(7), the declarative region of X includes only "the text of
the construct". No additional text is included because none of
8.1(8..11) apply.

Per 8.1(13), the declaration of X occurs "immediately within" the declarative_part of the body of P (see 7.2(2)).

The scope of the declaration of X starts immediately after the "1;" and
extends to the end of the immediately enclosing declarative region, per
8.2(2). Neither 8.2(3) nor 8.2(4) apply because X is not a library unit
and X is not declared in the private part of a library unit. Therefore,
X is visible only in the body of P, which is the immedtately enclosing declarative region.

package P.C is
private
X2 : Integer := X; -- (1)
end P.C;

The declaration of P.C occurs within the scope of the *declaration* of P
(its "declarative region", not in that of the *body* of P, per 8.1(16).

HTH
--
Ludovic Brenta.
Efficiency requires truly optimizing capital agility to add value.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

Ludovic Brenta <[email protected]> writes:

All of this is made super-explicit in 7.2(1) but a language lawyer
enjoys delving into details :)

I agree that the intent there is clear, but the annotated version of the reference manual seems to think that 7.2(1) is redundant
with... something, since it's placed it in square brackets, and I'd like
to find out what (and how!).

[email protected] writes:

For example:

package P is
pragma Elaborate_Body;
end P;

package body P is
X : Integer := 1;
end P;

Reading 8.1(7), the declarative region of X includes only "the text of
the construct". No additional text is included because none of
8.1(8..11) apply.

I don't see how the declarative region of X matters here for determining
its immediate scope, since the immediate scope is a portion of the immediately-containing declarative region, but this seems correct.

Per 8.1(13), the declaration of X occurs "immediately within" the declarative_part of the body of P (see 7.2(2)).

A package_body is not a declaration, and neither is a declarative_part
(though it may contain declarations) - they are not defined as
declarations anywhere I can find, including 3.1(6). Although a
package_body has its own declarative_part, neither a package_body nor a declarative_part have their own distinct declarative regions (8.1(2)
doesn't apply to a package_body both because it is not a declaration and because it is a completion, and none of 8.1(2..6) apply to a
declarative_part).

While we may informally speak of the declaration of X occurring
"immediately within" a declarative_part, 8.1(13) concerns itself only
with defining what it means for a declaration to occur immediately
within a declarative region, not an arbitrary syntactic construct like a declarative_part.

Because the declaration of X is within the declarative region of the declaration of P (due to 8.1(8)), and there is no declarative region
containing the declaration of X that is within the declarative region of
the declaration of P, the declarative region of the declaration of P is
the immediately enclosing declarative region of the declaration of X,
and the declaration of X occurs immediately within it.

This makes sense, because if either a package_body or a declarative_part
did have its own distinct declarative region it would not be possible to provide completions in the package body for declarations occuring within
the package declaration, see 3.11.1(3). In particular, for anything
declared immediately within the package body, it can only be interpreted
as a completion of something declared in the package declaration if it
occurs immediately within the declarative region of the package
declaration.

The scope of the declaration of X starts immediately after the "1;" and extends to the end of the immediately enclosing declarative region, per 8.2(2).

To my understanding the immediate scope of X starts at the "X" at the
beginning of the line per 8.2(2), since it is not an overloadable
declaration. It will, however, be hidden from all visibility until the
end of its declaration due to 8.3(16). I don't think that matters here,
though.

Neither 8.2(3) nor 8.2(4) apply because X is not a library unit and X
is not declared in the private part of a library unit.

Agreed.

Therefore, X
is visible only in the body of P, which is the immedtately enclosing declarative region.

As stated above, the immediately enclosing declarative region of X is
the declarative region of the declaration of P. As such, X's immediate
scope extends to the end of the declarative region of the declaration of
P, which includes the entirety of every child unit.

package P.C is
private
X2 : Integer := X; -- (1)
end P.C;

The declaration of P.C occurs within the scope of the *declaration* of
P (its "declarative region", not in that of the *body* of P, per
8.1(16).

P.C is declared immediately within the declarative region of the
declaration of P, yes, but this is the same declarative region that the declaration of X occurs immediately within.



This leaves the question... how then are we supposed to accomplish the
noble goals set out in 7.2(1)?

- Ulf Herrman

(P.S: as my gpg signature is apparently causing some issues for some
people, I have excluded it; be not alarmed)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

Dmitry A. Kazakov <[email protected]> wrote: |-------------------------------------------|
|"[. . .] a real language lawyer. I am not."| |-------------------------------------------|

Do not be modest! You are excellent at Ada!

Alas comp.lang.vhdl and comp.arch.fpga are not active. comp.lang.ada
is relatively active.

(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

Ulf Herrman schreib: |---------------------------------------------------------------------|
|"(P.S: as my gpg signature is apparently causing some issues for some| |people, I have excluded it; be not alarmed)" | |---------------------------------------------------------------------|

Thanks!
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.ada

Librarian2025 <[email protected]> wrote: |---------------------------------------------------------------------|
|"> Paganini.BOFH.team does not have this thread's original post (from|

Eternal September). |

| | |Probably was filtered out because of PGP signature." | |---------------------------------------------------------------------|

Thanks for diagnosing this! Paganini.BOFH.team also lacks news:[email protected]

Paganini.BOFH.team does not lack
news:[email protected]
(which does not have an encryption signature) by Ulf Herrman.

(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
--- Synchronet 3.22a-Linux NewsLink 1.2