Study Note on Alternative to MD 4.0 Hierarchical Library Feature ----------------------------------------------------------------- Robert B. K. Dewar 31 Jan 1992 The following is a sketch of a slightly different approach to the HL feature currently proposed in 9X. It is intended to meet the following criteria: 1. Allow all the capabilities and functionality of the current MD 4.0 proposal (with the exception of library level renames, which is an orthogonal issue). 2. Provide additional flexibility in access to private parts (e.g. solve the matrix-vector solution cleanly). 3. Maintain a syntax and general feel close to the current MD proposal. 4. Reduce recompilation costs 5. Simplify the description 6. Remove implementation objections to the current proposal 7. Improve security of Ada source programs Well that sounds like a good list (i.e. probably most people would agree if we could achieve all this), but, unlike the current presidential campaigning, promises of wonderful things with no pain, we need to see details! Here is the basic idea, it's quite easy to state: o Allow package names to contain dots, creating a hierarchical tree of names, but there is *no* implicit relationship between packages (compare files in a Unix file system) o Allow packages to be tagged private, with the same rule as in MD 4.0, which restricts access to private packages to the same tree (i.e. to packages having the same initial part of the name). o Introduce a "with private" notation, that, as previously suggested gives access to the private declarations of a package (in the same way that a body has such access, but not permitting completion of incomplete types). Now let's see how this meets the stated aims: 1. Allow all the capabilities and functionality of the current MD 4.0 proposal (with the exception of library level renames, which is an orthogonal issue). To get something which is close or identical (if it's not identical then there is something lurking in the MD which I do not understand!) to the MD proposal, we simply add appropriate "with private" declarations to all children, naming all their parents. Of course, as subsequently discussed, we may not want this much visibility and dependence. 2. Provide additional flexibility in access to private parts (e.g. solve the matrix-vector solution cleanly). This comes immediately from the "with private" notation. Another nice example of the need for this comes from the POSIX binding world. If you look at the POSIX binding (which in 9X would certainly come out as an HL tree of packages), then it is pretty clear that the implementation will typically need access to both the private declarations in key POSIX packages, and also private declarations in critical runtime system packages. 3. Maintain a syntax and general feel close to the current MD proposal. The general hierarchical feeling of the current proposal is maintained, and in particular, the imporant capability of having private library level specs, not accessible from outside the tree, is maintained. 4. Reduce recompilation costs This is an important point. The current MD proposal introduces a number of dependencies that may be inappropropriate and generate unnecessary recompilation work. Let's take an example: Suppose we are implementing package CALENDAR, using a collection of private packages CALENDAR.xxx which implement various aspects of the required functionality. These are all private, because we don't want the user to see any of the internals of CALENDAR. In particular, suppose we have a package: private package CALENDAR.LEAPYEAR is function IS_LEAP (YEAR : INTEGER) return BOOLEAN; function NEXT_LEAP (YEAR : INTEGER) return INTEGER; function PREV_LEAP (YEAR : INTEGER) return INTEGER; end CALENDAR.LEAPYEAR; Now this package is clearly not dependent on any other package, and in the modified proposal, recompilation of any component of the CALENDAR tree would not require recompilation of this package. In the MD proposal, there is an implicit with of CALENDAR and, for example, changing the definition of CALENDAR.TIME would force recompilation of CALENDAR.LEAPYEAR. Furthermore, the implicit dependence on CALENDAR is actively unhelpful in this case, since there is no dependence. It may seem to require extra writing to put all those with clauses in when they are required, but it is in the spirit of Ada to be explicit! 5. Simplify the description This claim depends on the proposition that describing and understanding with private is simpler than the current rules on the relationship between child packages and their parents. Clearly this has to be evaluated at the RM level, but I certainly find the with private concept straight forward conceptually, since it is after all essentially there already (in the visibility from a body to a spec). 6. Remove implementation objections to the current proposal The only significant issue in implementing this proposal is whether "with private" causes trouble. The main implementation objection to the MD 4.0 proposal has come from Rational (via Philippe Kruchten), and his preliminary assessment of this proposal is that it would significantly simplify the implementation effort. 7. Improve security of Ada source programs A consistent objection to the MD and other HL proposals has been the ability to "see into" private parts without the owner's permission. We have discussed this at some length, and the current position is that the general decision made by the MD (to allow such unauthorized visibility) is appropriate. However, the trouble with the MD proposal is that this private visibility is there all the time, whether it is wanted or not. The only way that a configuration tool could stop the (mis)use of such visibility is to completely disable the child library capability, which is much too severe. In this substitute proposal, a "with private" only appears if definitely needed. For example in the CALENDAR.LEAPYEAR example above, we know that this package cannot see (and of course does not need to see) into the private part of CALENDAR. We still have unauthorized access to private parts, but at least the unauthorized accessors have to announce themselves lound and clear with an explicit context clause, and it is a much more straightforward issue to create a configuration management tool which prevents such unwanted access. Note that we then have a situation much closer to Ada-83. In Ada-83, you know that modules cannot have unauthorized access to private parts unless they "with UNCHECKED_CONVERSION". A tool can check that this does not appear in a context clause. Now this tool simply needs to also check for "with private", and of course this is more selective, since we can decide that some private parts are accessible in this manner and others are not.