Re: Position of "use"

[anon@att.net]

Adam.

  Note: I was not talking or using option -gnat83, or 
pragma Ada_83. Only the "with_clause" and "use_clause" using
AdaEd and GNAT.

I used AdaEd and GNAT and their RM so anyone see what I am 
saying, because only AdaEd and GNAT compilers are downloadable 
and free and both have been validated, while the others 
compilers requires purchasing, and no guarantee they will work 
with current OS. Also, unsure if the sold IBM Apex compiler is 
even available to the general public.

Now, "-gnat83" basically just set the restrictions mode for 83,
like the pragma Ada_83.

  But, in the GNAT_RM  

   pragma Ada_83. states:

     "However, there is no guarantee that code that is processed 
     correctly by GNAT in Ada 83 mode will in fact compile and 
     execute with an Ada 83 compiler, since GNAT does not enforce 
     all the additional checks required by Ada 83."


Then there the change to "copy by type to the second stack" aka 
"Return by type" so, a number of Ada 83, 95, and early Ada 2005 
programs will no longer compile as initially written.

Which suggest that unless you using a pre-"Return by type" compiler 
that the pragma Ada_83, Ada_95 or Ada_05, or command options -gnat83, 
-gnat95, -gnat05 will not truly guarantee the code to be processed 
correctly. 

This one one reason I wish Adacore would make available for 
download the compiler source package for each Ada standard.
such as 
  GNAT 0.xx: initial version of gnat for Ada 83, Ada 95 code removed
  GNAT 3.1x: gnat for Ada 95
  GNAT 2011: gnat for Ada 2005

Or course it up to the downloader to find a way to compile the 
code. And add the correct gcc back_end.



Also most people use GNAT by either 
            gnat make <program_name>

or when binding to other languages.
            gnat compile <program_name>.adb
            gnat build <program_name>.ali
            gnat link <program_name>.ali  <non-Ada object code list>

while the other 10+ routines like chop are not normally used.

Plus, GNAT "Chop" splits the file by looking for the end of 
the "library_unit" or "secondary_unit". Any statement after the 
end of the unit begins on the next file, this can include comments 
after unit.  Also, "Chop" does not check for configuration pragmas 
because GNAT does not support theses pragmas ( System_Name, 
Memory_Size, Storage_Unit ).



In <f02e3f5c-dcfc-4d69-9caa-ee0f14723f70@googlegroups.com>, Adam Beneschan <adambeneschan@gmail.com> writes:
>On Tuesday, July 15, 2014 10:01:12 AM UTC-7, Simon Wright wrote:
>
>> But, in Ada83, a *pragma*'s scope extended over the whole compilation
>> (all the compilation units).
>
>I don't know that this was universally true; I don't see a general rule to =
>that effect.  The rules vary from pragma to pragma.  STORAGE_UNIT and SYSTE=
>M_NAME (since removed) had to appear at the beginning of a compilation and =
>applied to every compilation unit in the compilation (this seems to anticip=
>ate the "configuration pragma" rules of Ada 95 and beyond).  ELABORATE, how=
>ever, appears in a context clause (as does the "use" clause) but only appli=
>es to one compilation unit.  Most of the pragmas were only allowed inside d=
>eclarations.  LIST(ON) and LIST(OFF) apply to the entire compilation, of co=
>urse, but since it controls only the listing output and has no effect on se=
>mantics or generated code, it's really a special case.  Implementation-defi=
>ned pragmas follow whatever rules the vendor decides they should.
>
>I think the situation is pretty much the same in Ada 95+, except a little m=
>ore formalized.  There's no one rule defining the scope of pragmas, but the=
>re are rules for categories of pragmas (in particular "configuration pragma=
>s").
>
>                            -- Adam