ARG-Editor
commented
3 months ago The existing proposal is found in AI12-0239-1, known as "Ghost code". The basic idea is that entities can be tagged as conditional code with an aspect; the aspect takes a name that can be chosen by the user. Various rules are enforced so that non-conditional code cannot depend on conditional code except in specific, specified ways. For instance, use of conditional code in assert expressions (like Pre and Post) is allowed. Conditional code can read, but not write, non-conditional data. A pragma Ghost_Policy can be used to turn on or off specific code groupings.
This proposal was extensively discussed (in part over enormous hamburgers!) during the Warsaw ARG meeting in 2019. Some, but not all, of the results of that discussion are reflected in the AI. Additionally, a lot of detail still needs to be worked out.
Since that meeting, concern has been raised that the term "ghost" is rather specific to the usage for assertions (even though the mechanism is useful for more than that). A different term should be considered (I've tried to avoid using "ghost" in this discussion other than for discussing the existing proposal, although for the expected usages and rules it seems OK to me).
The big advantage of this proposal is that code that compiles once with any particular Ghost_Policy setting will continue to be legal in other Ghost_Policy settings (with the remaining limitation on value-dependent code, see the discussion of static conditional code for more on that limitation).
The proposal appears to meet all of the criteria set out in the introductory part, but of course many details still need to be worked out.
Ideally, some interested parties would come together (in a LSG) to work out and prototype a more complete proposal.
dhombios
sttaft
joshua-c-fletcher
Richard-Wai
evanescente-ondine
[This issue has been opened to continue work on an unfinished topic from Ada 2022. This was done in response to the ARG Resolution of November 2022. This is the last topic that will be "promoted" this way.]
It is very common for program units to come in multiple versions. This often manifests as small chunks of code that belong only to one version or another. These chunks can be handled with runtime selection, but in some enviroments (particularly some safety-critical environments), any code that can be executed has to be verified in various ways. Code that is unused in the delivery version still costs time and money to handle. Mechanisms need to exist to ensure that such code does not exist in the final versions.
For instance, "production" and "testing" versions of code are quite common. "Testing" version often have extra tracing and assertions that are unnecessary (or even harmful) in the final program.
Another example is when extra code is needed to support verification. It commonly is the case that additional data and functions are needed to support program verification. It is best if that code can be omitted from final versions of programs (and sometimes even testing versions).
We call these small chunks of code that only belong to some versions "conditional code".
Current mechanisms and problems
The Ada programming language does not provide any special mechanisms to handle conditional code (we'll discuss why later). One commonly used approach solely within the Ada language is to control such code with static Boolean values.
This usually works even for safety-critical applications as most compilers can eliminate code that clearly can never be executed. However, this technique is of limited applicability.
It cannot be used on entities, such as objects or subprograms. Other techniques might be able to eliminate these, but at the source level they are not clearly included in the conditional code (one cannot surround them with an if statement, particularly at library level).
It requires some sort of editing to change the mode. The static Ada boolean object has to have its value changed in order to go from one mode to another. This can be minimized by placing the object into a commonly used package, and might be able to be automated by some technique outside of the language, but it cannot be totally eliminated. Indeed, any technique, in the language or outside of it, will ultimately require some way to set the mode. To stay purely in the language, that would necessarily require editing, since compile options and other schemes are necessarily not part of the language.
It cannot be used on pragmas. Pragmas such as Suppress and Assertion_Policy often differ between program versions. Most compilers have options to manage the most popular pragmas, but of course such options are not portable and may not cover some of the more obscure possibilities (such as Restrictions pragmas).
Value-dependent code can cause compile-time errors in other modes. Ada has rules requiring static expressions with errors to be rejected. For example, in some code like: if Bucket_Tracing then Put_Line (Integer'Image(Item_Num/Max_Bucket_Count) & " average items per bucket"); end if; If the "buckets" are part of the debugging system, and thus the number of buckets is zero when Bucket_Tracing is False, the above code is illegal because it contains a divide-by-zero -- even though the tracing code will never be executed. This is annoying; it can be worked around by making Max_Bucket_Count or Item_Num nonstatic, but of course that means extra code is being used for no reason.
As such, Ada currently only covers part of the problem.
Ada vendors are of course aware of these problems and provide various techniques to help these issues. One way that can be done is with project management schemes (such as project files and processors). A project management scheme provides a way to select different versions of units and of compiler options for different versions of a program. These schemes can range from fairly simple to quite elaborate.
But they all suffer from not being part of the language. One obvious way is that they only work for a single vendor's tools. If one switches vendors, all of the project management artifacts have to be rebuilt.
Another problem is that a change in a package specification (which is certain to happen in long-lived developments) means that all of the other versions of that package have to be changed similarly. But those other versions might belong to other teams (as happens for different targets of a compiler), and there is no semi-automated way to ensure that all of the versions are changed appropriately.
Even when the other versions are just of the bodies of the package (with a single shared specification), additions to the specification can be problematical. Other teams owning bodies will suddenly find (usually at the worst possible time) that they cannot compile their project, and may have difficultly understanding what the new additions need to do.
Finally, versioning at the package level usually means that a lot of code needs to be duplicated between all of these versions. Keeping that code (which should not be different) in sync adds another headache to managing versions in a project management scheme.
Another way that vendors can help this problem is through bind-time optimizations. At the time of binding an Ada program, all of the code and data usage for that program can be determined, thus any unused code or data can be removed. This technique requires no code changes at all to eliminate unused entities.
In practice, there are three main ways that that can be accomplished. First, the (previously) compiled binary code can be augmented with enough information so that unused code and data can be determined, and then eliminated. Second, conversion to binary machine code can be delayed until bind-time, when much more information about the full program is available. Third, one could determine the code used by the final program and create modified source code that doesn't include the unused entities.
However, these sorts of techniques are not commonly implemented today. Janus/Ada has included a version of the first method since the mid-1980s. GNAT has some tools that appear to use the third method. Some compilers for other languages use the second method.
Additionally, this technique can only work on Ada code, so there still is no help here for pragma changes when the mode changes. And of course source editing (or going outside of the language) is still necessary for changing modes.
Another approach commonly used for handling this problem works mostly or completely at the lexical level. This usually is some combination of include files and macro processing. The C system is the best known example.
These sorts of systems typically allow writing almost any entity (and often parts of entities) in a conditional manner. The compiler is presented a particular version based on settings (often compiler options).
These techniques were well known when Ada was designed, and were available as part of many popular program language implementations (if not the language itself). So why did the Ada designers avoid them??
Mostly likely, they were trying to avoid the problems that come from lexical schemes used in large system with many options. In such situations, it is common that the code for some combinations of options is not even legal (since the code is constructed at the lexical level, it is easy to create bad syntax). When there are many options, it is impractical to test all of the combinations, so many go untested and thus may not even be possible to compile. Since Ada keeps all conditional compilation within the language, it avoids this problem: all code is compiled, and therefore is checked for legality, even if it can never be executed with the current set of options.
What we'd really want is a mechanism that is: (1) Part of the language, so it is widely available; (2) Allows any sort of entity to be conditionally compiled; (3) Allows any pragma to be included (or not) in a given version; (4) Allows the specification of as many separate options as is needed; (5) Ensures that no code or data is needed for entities not included in the current version.
We haven't talked about point (4) yet, so let's take a look at that.
Typically, any significantly sized system will need multiple levels of testing, multiple levels of specification, and often multiple items of configuration. A single setting is not enough.
For instance, in contracts, it is common for there to be three kinds of routines. There are some routines which are impractical to evaluate at runtime (these often describe properties of the target that are not easily determined). There are more routines that can be evaluated, but are too expensive to evaluate all the time. An example is Is_Sorted for the Vector containers. The result of Merge is only well-defined for inputs that are sorted, but Is_Sorted is expensive and calling it each time would substantially slow testing. One only wants to do that if a problem in that area is suspected. On the other hand, many queries are cheap. In the vector container, Is_Empty is cheap (a single integer test); it should be run during all testing (even if it is to be eliminated in the fielded system).
Similarly, tracing code is often split into groups on large programs. Running all tracing can be impractical. For instance, running all tracing in Janus/Ada generates a larger than 3MB file even on the smallest ACATS tests. Even if one can load the file, finding the item of interest in it is very difficult. It's much better to only run a few traces of interest.
More generally, language features that can only be used one way have been avoided in the Ada design. Ada tries to take a more building block approach, so that the features it has can be combined to solve many problems, not just a single one. Some of the places where that was not done (such as stream attributes), have been a pain point. We want to avoid introducing more such points.
We'll take a look at the existing proposal in my next message.