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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d121cc76e012fcca
X-Google-Attributes: gid103376,public
From: "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com>
Subject: Re: Library Level Question
Date: 1999/02/15
Message-ID: <7a9p96$khq@hobbes.crc.com>#1/1
X-Deja-AN: 444664930
References: <36c853cb.0@news.pacifier.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Organization: Coleman Research Corporation
Newsgroups: comp.lang.ada
Date: 1999-02-15T00:00:00+00:00
List-Id: <comp.lang.ada>


Steve Doiel wrote in message <36c853cb.0@news.pacifier.com>...
>What exactly is meant by Library Level
>
>Section 13.10.2 of the LRM gives the following description:
>
>  (22)
>  The accessibility level of all library units is called the library level;
>a library-level declaration or entity is one whose accessibility level is
>the library level.
>
>Does this mean unit specifications? Implementations? Either?
>I'm obviously not a language lawyer, but am often able to figure things out
>from the LRM.  this has been an exception.
>
>My observation has been that when I try to take the address ('access) of a
>function or procedure that is defined within my main procedure, I get a
>message about the wrong library level.  But if I take the address of a
>function or procedure defined inside a package spec or body, the compiler is
>happy.
>
Subprograms declared in packages are at library level, as are subprograms
such as your main program itself.  For example, you could call any procedure
eligible to be a main procedure from within any other subprogram, merely by
mentioning the procedure in a context clause (with).  But, subprograms
nested within that main-eligible procedure are not visible outside that
procedure, hence are not at library level.

Any subprogram which does not make use of variables external to it can be
defined by itself in a file -- only the body is required, because the
subprogram body exposed at library level is its own specification.

Here's an example:

--
-- File Name: util-execute_shell_command.adb
--

with Ada.Characters.Latin_1;
with System;
function Util.Execute_Shell_Command
           (The_Command : String) return Integer is
   function Execute
              (The_Command_Address : System.Address) return Integer;
   pragma Import (C, Execute, "system");
   The_Nul_Terminated_Command_String : constant String :=
     The_Command & Ada.Characters.Latin_1.Nul;
begin
   return Execute (The_Nul_Terminated_Command_String'Address);
end Util.Execute_Shell_Command;

So, a unit that has the context clause
"with Util.Execute_Shell_Command;"

can take the 'Access attribute of the Execute_Shell_Command function,
but not the nested Execute function.

Of course the parent package Util must also be present for this example
to work -- e.g.:
--
-- File: util.ads
-- This specification is the parent for all UTIL specifications.
-- UTIL is the subsystem for utilities.
--
package Util is
   pragma Pure (Util);
end Util;

I hope this is both sufficiently "layman's langusge" and clear.

David C. Hoos, Sr.