comp.lang.ada
 help / color / mirror / Atom feed
From: Adam Beneschan <adambeneschan@gmail.com>
Subject: Re: Position of "use"
Date: Thu, 10 Jul 2014 08:54:52 -0700 (PDT)
Date: 2014-07-10T08:54:52-07:00	[thread overview]
Message-ID: <f1e5d652-e013-4c22-897e-28b040638945@googlegroups.com> (raw)
In-Reply-To: <lpkq5a$6ir$1@speranza.aioe.org>

On Wednesday, July 9, 2014 6:27:08 PM UTC-7, an...@att.net wrote:
> Actually, the comments for compilation_unit 4 are correct under multiple 
> compilation_unit type files, which GNAT does not support. It was tested 
> under AdaEd-1.11.0a compiled for SuSE Linux, before I posted a condensed 
> version.

The language rules are clear.  10.1.2(5) says that the scope of a with_clause that appears on a library unit declaration consists of the entire declarative region of the *declaration*, which includes all children and subunits (and, by 8.1(8), includes the package body if the with_clause appears on a package specification).  If a file contains two compilation units, they are two separate declarations.  Therefore, unless the second declaration is a body or child unit or subunit of the first one, the scope of a with_clause on the first unit in a file does not include the second unit.

The fact that one or another compiler accepts it means nothing.  Compilers have bugs.  Compiler bugs that allow illegal code to be accepted are given less attention, in my experience, than compiler bugs that reject legal Ada code or generate incorrect object code.  That's certainly the case with GNAT, which has a number of bugs in which illegal code is accepted (which unfortunately means that open-source Ada projects that get put on the Internet sometimes have illegal Ada in them).  But to determine whether a construct is legal or an identifier is visible or whatever, you have to check the language standard; you cannot count on a compiler to get it 100% right.


> For multiple compilation_unit, likes those files found in ACVC, the 
> external visibility starts with the "with_clause" and that clause 
> grants all succeeding compilation_unit(s) access to that package or 
> routine no matter how many compilation_unit there are. In other words 
> you only need one "with_clause" for Ada compilers that support multiple 
> compilation_unit in the same file. 

No, that isn't true.  It may *appear* to be true in the ACATS because a later compilation unit is often the completion (body) of an earlier one, or it's a child unit.  And, as I pointed out, with_clauses on package specs *do* apply to their bodies and child units.  But if you can find a case where a with_clause on one package in a ACATS file applies to a later *unrelated* package, please post it.  (But really, don't bother, because there aren't any.  If there were, our compiler would have caught it a long time ago.)

                                  -- Adam


      parent reply	other threads:[~2014-07-10 15:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-05  6:43 Position of "use" Victor Porton
2014-07-05  7:12 ` J-P. Rosen
2014-07-07 16:45   ` Adam Beneschan
2014-07-07 17:08     ` Pascal Obry
2014-07-07 17:40       ` Peter Chapin
2014-07-07 19:17       ` Adam Beneschan
2014-07-08  5:26     ` J-P. Rosen
2014-07-08 15:32       ` Adam Beneschan
2014-07-08 19:30 ` Adam Beneschan
2014-07-08 22:39   ` Victor Porton
2014-07-09 10:36 ` anon
2014-07-09 15:14   ` Adam Beneschan
2014-07-10  1:27     ` anon
2014-07-10  9:50       ` AdaMagica
2014-07-10 13:10         ` J-P. Rosen
2014-07-10 15:57           ` Adam Beneschan
2014-07-10 17:47             ` Tero Koskinen
2014-07-10 19:15           ` Jeffrey Carter
2014-07-15  5:56         ` anon
2014-07-15  7:36           ` Georg Bauhaus
2014-07-15 17:01             ` Simon Wright
2014-07-15 17:23               ` Jeffrey Carter
2014-07-15 19:44                 ` Simon Wright
2014-07-15 17:47               ` G.B.
2014-07-15 17:51               ` Adam Beneschan
2014-07-15 20:04                 ` Simon Wright
2014-07-16  7:19                 ` anon
2014-07-10 15:54       ` Adam Beneschan [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox