* Library Level Question @ 1999-02-15 0:00 Steve Doiel 1999-02-15 0:00 ` David C. Hoos, Sr. 1999-02-15 0:00 ` Matthew Heaney 0 siblings, 2 replies; 9+ messages in thread From: Steve Doiel @ 1999-02-15 0:00 UTC (permalink / raw) 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. Please respond in layman terms (if possible). SteveD ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library Level Question 1999-02-15 0:00 Library Level Question Steve Doiel @ 1999-02-15 0:00 ` David C. Hoos, Sr. 1999-02-15 0:00 ` Matthew Heaney 1 sibling, 0 replies; 9+ messages in thread From: David C. Hoos, Sr. @ 1999-02-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library Level Question 1999-02-15 0:00 Library Level Question Steve Doiel 1999-02-15 0:00 ` David C. Hoos, Sr. @ 1999-02-15 0:00 ` Matthew Heaney 1999-02-15 0:00 ` Steve Doiel 1999-03-01 0:00 ` Robert A Duff 1 sibling, 2 replies; 9+ messages in thread From: Matthew Heaney @ 1999-02-15 0:00 UTC (permalink / raw) "Steve Doiel" <nospam_steved@pacifier.com> writes: > What exactly is meant by Library Level I think of library level as the most outer scope of a system. Think of a real library. All the books in the library are at "library level." But if you open one of the books, and look at a diagram, then the diagram is _not_ at library level, because it's _inside_ the book. But the book itself is "inside" the library. All the things we think of as being inside the library are at library level (say, the things listed in the card catalog). In contrast, a diagram is "more nested," because it's inside the book, not inside the library (and the diagram would not be in the library's card catalog). > 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. This just means that when you have a package, not declared in anything else, as in package Book is ... end Book; that it is at library level. Just like our book. But if we have a package inside another, like this: package Book is package Diagram is ... end Diagram; ... end Book; then the inner package is _not_ at library level. The diagram is in the book, not the library. > 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. Because inside a procedure, you're not at library level, you're inside something. Stretching our analogy a bit, it's like trying to give a reference to a diagram, without having to also refer to the book, and that's illegal. You have a couple of choices: 1) Declare the subprogram you want to call via a pointer inside a package at library level: package Book is procedure Diagram; end; Now you can safely point to subprogram via a pointer. 2) If you're using GNAT, then you can go outside the Official Language by using 'Unrestricted_Access. You are then allowed to point to your local subprogram, without any complaints from the compiler. This "feature" of the language has been debated many times here on c.l.a. Go to DejaNews and search for "downward closures" to get more info. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library Level Question 1999-02-15 0:00 ` Matthew Heaney @ 1999-02-15 0:00 ` Steve Doiel 1999-02-15 0:00 ` kirk 1999-03-01 0:00 ` Robert A Duff 1 sibling, 1 reply; 9+ messages in thread From: Steve Doiel @ 1999-02-15 0:00 UTC (permalink / raw) >But if we have a package inside another, like this: > >package Book is > > package Diagram is > > ... > end Diagram; > >... >end Book; > > >then the inner package is _not_ at library level. The diagram is in the >book, not the library. > Thank you, I believe the concept of library level is clear to me now. If I understand correctly, your example is in slight error in that package Diagram is at the library level, but its contents are not. SteveD ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library Level Question 1999-02-15 0:00 ` Steve Doiel @ 1999-02-15 0:00 ` kirk 1999-02-16 0:00 ` Steve Doiel 0 siblings, 1 reply; 9+ messages in thread From: kirk @ 1999-02-15 0:00 UTC (permalink / raw) In article <36c8d860.0@news.pacifier.com>, "Steve says... > >>But if we have a package inside another, like this: >> >>package Book is >> >> package Diagram is >> >> ... >> end Diagram; >> >>... >>end Book; >> >> >>then the inner package is _not_ at library level. The diagram is in the >>book, not the library. >> > >Thank you, I believe the concept of library level is clear to me now. > >If I understand correctly, your example is in slight error in that package >Diagram is at the library level, but its contents are not. > huh? package diagram is NOT at library level. That is the whole point of the example! Kirk. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library Level Question 1999-02-15 0:00 ` kirk @ 1999-02-16 0:00 ` Steve Doiel 1999-02-23 0:00 ` Tucker Taft 0 siblings, 1 reply; 9+ messages in thread From: Steve Doiel @ 1999-02-16 0:00 UTC (permalink / raw) >>If I understand correctly, your example is in slight error in that package >>Diagram is at the library level, but its contents are not. >> > >huh? > >package diagram is NOT at library level. That is the whole point of >the example! > Back to the example, with a couple of procedures added: package Book is procedure Read is begin end Read; package Diagram is procedure Draw ... ... end Diagram; ... end Book; In this example the procedure "Read" is a the library level and the procedure "Draw" is not at the library level. Any declarations between "procedure Read" and "end Read" are not at the library level (only the interface is at the library level). Similarly anything between "package Diagram" and "end Diagram" is not at the library level, but the interface is at the library level. Suppose the diagram package were made a generic. I could create an instance of the generic since it is at the library level, but I could not see inside the generic. If I'm off base, let me know. SteveD ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library Level Question 1999-02-16 0:00 ` Steve Doiel @ 1999-02-23 0:00 ` Tucker Taft 0 siblings, 0 replies; 9+ messages in thread From: Tucker Taft @ 1999-02-23 0:00 UTC (permalink / raw) There are several mistaken replies here. Library unit packages are at library level, as are all their contents, both spec and body. You only "leave" library level by going inside a subprogram, a type, a generic, etc. You *stay* at the same level when you enter a sub-package. Accessibility level relates to "lifetime." The contents of a package live as long as the package itself. On the other hand, the declarations inside a subprogram last only as long as any given *call* on the subprogram, whereas the subprogram itself lasts as long as the enclosing scope lives. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library Level Question 1999-02-15 0:00 ` Matthew Heaney 1999-02-15 0:00 ` Steve Doiel @ 1999-03-01 0:00 ` Robert A Duff 1999-03-08 0:00 ` Matthew Heaney 1 sibling, 1 reply; 9+ messages in thread From: Robert A Duff @ 1999-03-01 0:00 UTC (permalink / raw) The explanation below is not quite right. "Library level" means anything whose lifetime is essentially forever -- ie it lasts until the end of the whole program. A variable (or anything else) can be nested inside as many packages as you like, and it lasts "forever". That's library level. OTOH, if it's nested inside a procedure, function, or task, then it's not at library level -- its lifetime ends when the containing procedure returns, or whatever. I think "library level" was a poor choice of terms, because it makes people think of "library unit", which isn't quite right. Matthew Heaney <matthew_heaney@acm.org> writes: > This just means that when you have a package, not declared in anything > else, as in > > package Book is > ... > end Book; > > that it is at library level. Just like our book. > > But if we have a package inside another, like this: > > package Book is > > package Diagram is > > ... > end Diagram; > > ... > end Book; > > > then the inner package is _not_ at library level. The diagram is in the > book, not the library. -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library Level Question 1999-03-01 0:00 ` Robert A Duff @ 1999-03-08 0:00 ` Matthew Heaney 0 siblings, 0 replies; 9+ messages in thread From: Matthew Heaney @ 1999-03-08 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > The explanation below is not quite right. "Library level" means > anything whose lifetime is essentially forever -- ie it lasts until the > end of the whole program. A variable (or anything else) can be nested > inside as many packages as you like, and it lasts "forever". That's > library level. OTOH, if it's nested inside a procedure, function, or > task, then it's not at library level -- its lifetime ends when the > containing procedure returns, or whatever. > > I think "library level" was a poor choice of terms, because it makes > people think of "library unit", which isn't quite right. After I posted that response, I regretted it, because I knew it wasn't right. I was thinking of a few years back when I was using the VMS Ada compiler. They had a restriction about the location of procedures that could be exported: they had to be at "library level" (DEC's term). What that meant to them was that this was legal: package P is procedure Op (O : T); pragma Export (Op); end P; But this was illegal: package P is package Nested is procedure Op (O : T); pragma Export (Op); end Nested; end P; Ada95 has finally solved these problems; I just need to get my terms straight. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-03-08 0:00 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-02-15 0:00 Library Level Question Steve Doiel 1999-02-15 0:00 ` David C. Hoos, Sr. 1999-02-15 0:00 ` Matthew Heaney 1999-02-15 0:00 ` Steve Doiel 1999-02-15 0:00 ` kirk 1999-02-16 0:00 ` Steve Doiel 1999-02-23 0:00 ` Tucker Taft 1999-03-01 0:00 ` Robert A Duff 1999-03-08 0:00 ` Matthew Heaney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox