From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.224.2.137 with SMTP id 9mr12235718qaj.2.1372696280433; Mon, 01 Jul 2013 09:31:20 -0700 (PDT) X-Received: by 10.50.67.74 with SMTP id l10mr847780igt.0.1372696280345; Mon, 01 Jul 2013 09:31:20 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!news.bbs-scene.org!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!y2no8943qax.0!news-out.google.com!f7ni507qai.0!nntp.google.com!y2no8941qax.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 1 Jul 2013 09:31:20 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <63a787e1-c3d9-4bfd-a7e6-6ff0f0c8236b@googlegroups.com> <22fdedd9-f5e2-4489-bd41-7fb3b21e9992@googlegroups.com> <7f402618-da9e-4c01-85b8-5742a7b89b31@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: "shadow" package hierarchy using renaming of child packages From: Adam Beneschan Injection-Date: Mon, 01 Jul 2013 16:31:20 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:16017 Date: 2013-07-01T09:31:20-07:00 List-Id: On Sunday, June 30, 2013 10:46:24 PM UTC-7, J-P. Rosen wrote: > 10.1.1(13): The parent unit of a library_item shall be a library package > or generic library package >=20 > ... and not a library_package_renaming_declaration Also, 10.1.1(15) is more explicit, I think: "A parent_unit_name (which can = be used within a defining_program_unit_name of a library_item and in the se= parate clause of a subunit), and each of its prefixes, shall not denote a r= enaming_declaration." The name following the word "package" is a defining_= program_unit_name, therefore any ancestor unit name that's part of the defi= ning_program_unit_name can't be a renaming unit. I don't think it's an arbitrary restriction, either. Child units are able = to directly access names defined in their ancestor units. If we were able = to write package A.B.C renames X.Y.Z; =20 package A.B.C.D is ... A.B.C.D would have direct visibility to names declared in its ancestors--bu= t what are its ancestors? A and A.B, or X and X.Y? Keep in mind that the = ancestor A.B.C is a rename of X.Y.Z and the specification of X.Y.Z will be = able to directly refer to names in X and X.Y. I think that allowing A.B.C.= D here would lead to a big semantic mess. -- Adam