Version 1.9 of ais/ai-00362.txt

!standard 03.09(06) 04-02-02 AI95-00362/06
!standard 11.04.01(02)
!standard 11.04.01(03)
!standard 13.07(03)
!standard 13.07(36)
!standard 13.07.1(03)
!standard 13.07.1(15)
!standard A.03.02(02)
!standard A.04.02(03)
!standard A.04.06(03)
!standard A.04.07(46)
!standard C.07.01(02)
!standard D.05(03)
!standard D.10(03)
!standard D.11(03)
!class amendment 03-11-26
!status Amendment 200Y 04-06-29
!status WG9 approved 04-11-18
!status ARG Approved 9-0-0 04-06-13
!status work item 03-11-26
!status received 03-10-04
!priority Medium
!difficulty Medium
!subject Some predefined packages should be recategorized

Predefined Ada packages should be categorized as restrictively as possible, in order for them to be as widely applicable as possible. AI-161 provides a mechanism to allow more packages to be preelaborated. AI-366 loosens the restrictions on pure packages. All Ada 95 packages should be checked to insure that they are categorized correctly.

Preelaborated units automatically eliminate some sources of potential error (including some checks that otherwise would have to be done at runtime). Thus, it is to the advantage of Ada programmers to use them whereever possible. But the categorization of predefined packages makes that impossible in many cases where it otherwise would be possible:

* Ravenscar and other restricted environments map naturally to preelaborated units, but most real-time packages can't be used in preelaborated units.

* Raising and handling exceptions with information is needed in preelaborated units; but Ada.Exceptions is not usable in such units;

* All forms of I/O are prohibited in preelaborated units (no predefined I/O package is preelaborated), making it difficult to use preelaborated units in environments where logging/field debugging are necessary (such as unattended servers).

Ada.Asynchronous_Task_Control is declared preelaborated. Ada.Characters.Handling is declared pure. Ada.Dynamic_Priorities is declared preelaborated. Ada.Exceptions is declared preelaborated. Ada.Strings.Maps is declared pure. Ada.Strings.Maps.Constants is declared pure. Ada.Synchronous_Task_Control is declared preelaborated. Ada.Tags is declared preelaborated. Ada.Task_Identification is declared preelaborated. System is declared pure. System.Storage_Elements is declared pure.

package Ada.Exceptions is pragma Preelaborate(Exceptions); type Exception_Id is private; pragma Preelaborable_Initialization (Exception_Id); Null_Id : constant Exception_Id; function Exception_Name(Id : Exception_Id) return String;

type Exception_Occurrence is limited private; pragma Preelaborable_Initialization (Exception_Occurrence); type Exception_Occurrence_Access is access all Exception_Occurrence; Null_Occurrence : constant Exception_Occurrence;

package Ada.Task_Identification is pragma Preelaborate(Task_Identification); type Task_ID is private; pragma Preelaborable_Initialization (Task_Id); Null_Task_ID : constant Task_ID; function "=" (Left, Right : Task_ID) return Boolean;

with System; with Ada.Task_Identification; -- See C.7.1 package Ada.Dynamic_Priorities is pragma Preelaborate(Dynamic_Priorities);

with Ada.Task_Identification; package Ada.Asynchronous_Task_Control is pragma Preelaborate(Asynchronous_Task_Control);

Here we list all Ada 95 predefined packages and their standard categorization. (We do not consider Annex E categorization here; AI-126 did that, and there are not any proposed changes that would change the results of that AI.) Packages that are not already either pure or preelaborated are examined to see whether they should be given pragma Preelaborate; packages that are preelaborated are examined to see whether they should be given pragma Pure. The run-time implementation of two compilers (GNAT and Janus/Ada) also are examined for impacts of any proposed change.

Remember that any dependences of a pure unit must be pure and any dependences of a preelaborated unit must be pure or preelaborate.

We also asked implementers for comments on the difficulty of implementing the first version of this proposal. Two implementers responded. DDCI reported that they made the changes proposed and that no problems surfaced other than with Ada.Characters.Mapping (which is solved by more recent versions of the proposal). They would not want to see more extensive changes.

IBM Rational reported that making the I/O packages preelaborated would require some rework. Moreover, Sequential_IO and Direct_IO included elaboration-time size determinations.

They noted that it would always be possible to rewrite the packages to an initialize-state-on-use strategy. (That is always a possible implementation when a package depends on complex state initialized at elaboration time.) They were concerned that a simple version of this (using a simple Boolean flag) would be fragile in the face of tasking. (Two tasks could trigger execution of the initialization at the same time). To fix that, a protected object (and its overhead) would be required. In addition, such a technique could be needed in a host of support units. Thus, restructuring of large parts of the runtime could be needed.

Because of these points (and the fact that other implementers expressed agreement with them), we did not propose to make any unit with significant initial state preelaborated.

This package depends on Ada.Task_Identification, so it cannot be pure. This package is really an interface to the tasking runtime, and any state needed is there. There should be no need for any separate initialization. The task runtime must be able to be called from a pure package (it is perfectly possible to declare or rendezvous with a task in a pure package). Thus, this package should be Preelaborated.

Some systems implement Clock by determining the difference between an initial time and the current time. Getting the initial time requires (system) subprogram calls during elaboration, which is not allowed in a preelaborated unit.

For example, many Windows implementations use a combination of the system time function and the high performance counter to provide decent precision for Clock. The high performance counter is just a 64-bit counter for which the elapsed time is the difference between two values. For this, an initial value must be saved. Both the GNAT and Janus/Ada implementations use this technique. Thus, making the package Preelaborated could cause an intolerable performance incompatibility.

Oddly, AI-161 declares Ada.Calendar.Time as a type that has preelaborable initialization, even though it is in a non-preelaborated package. The text of the AI suggests that this is a mistake (it claims that these types are declared in preelaborated packages).

This package contains no state, no dependence on non-pure units, no items that prevent the package from being pure, and does not declare any types (so there is no problem with Annex E). The only possible reason for not declaring this pure is so that it can be implemented by using Ada.Strings.Maps. But this routine isn't complex enough for that to be any real benefit. (And we're also proposing to change Ada.Strings.Maps.) This package should be declared pure.

GNAT's implementation does with and use Ada.Strings.Maps, but does not appear to actually reference it anywhere. Janus/Ada's implementation does not depend on any other package.

This package has state -- the program's command line -- and thus cannot be pure.

Any state that the operations need should be contained in the File_Type object; separate state is not needed.

However, most Ada implementations depend on a central IO package to implement all of the I/O. This package implements various operations that require state, such as file cleanup (to deal with files left open by the program), OS identification and the like. At least one implementer noted that extensive rewriting of the package would be needed to make it preelaborated. They also determined the size of file records at elaboration time.

The two implementations that we studied do not have problems. GNAT uses a controlled object to clean up files in a package used by Direct_IO. There is no other state in any of the packages. Janus/Ada uses a small amount of state in a package used by Direct_IO, this could be moved to Open/Create. There is no other state.

Still, given that a change here could cause extensive work, we are not recommending a change in categorization for Direct_IO.

The package cannot be pure because it contains named access types (which do not meet any of the exceptions in AI-366). Moreover, many of its operations are not conceptually pure (they have significant side-effects).

The package Ada.Exceptions was not preelaborated in Ada 95 because of the default initialized objects Null_Id and Null_Occurrence. With appropriate use of pragma Preelaborable_Initialization, this limitation can be eliminated. The package has no state of its own, and the routines it depends upon must be able to be called from a pure package (it is perfectly possible to raise and handle an exception in a pure package). Thus, this package should be Preelaborated.

GNAT's implementation uses a lot of dependencies and state; we can't tell if this change would be difficult to implement. Janus/Ada uses a 'built-in' implementation of this package, thus the categorization has no impact on the implementation.

The operations defined by this package are not conceptually pure, so this package should not be pure.

Depends on Ada.Text_IO; see that unit for discussion.

Depends on Ada.Wide_Text_IO; see that unit for discussion.

Depends on Ada.Text_IO; see that unit for discussion.

This package may need to execute code and/or system calls to gather the initial state (the default handlers) of interrupts. Thus, the package cannot be preelaborated.

Depends on Ada.Interrupts; see the discussion of that unit.

Ada.IO_Exceptions -- A.13; Pure Ada.Numerics -- A.5; Pure Ada.Numerics.Complex_Elementary_Functions -- G.1.2; Pure Ada.Numerics.Complex_Types -- G.1.1; Pure Ada.Numerics.Discrete_Random -- A.5.2; not categorized

The AARM notes that this cannot be pure, because the private part will require an access type. All of the state should be implemented in the generator object, so no initialization should be needed at elaboration time. However, the implementation does have to depend on Ada.Calendar (or an equivalent) to implement the one parameter Reset. Thus, since Calendar is not preelaborated, neither can this package be preelaborated. Moreover, the rule of A.5.2(39) requires execution of a statement at instantiation elaboration time.

Neither GNAT nor Janus/Ada have any state here; both depend on Ada.Calendar. Janus/Ada does execute some code at elaboration time to implement A.5.2(39); GNAT makes this check on each call to Random (which doesn't correctly implement A.5.2(39)).

Neither GNAT nor Janus/Ada have any state here; both depend on Ada.Calendar.

Ada.Numerics.Generic_Complex_Elementary_Functions -- G.1.2; Pure Ada.Numerics.Generic_Complex_Types -- G.1.1; Pure Ada.Numerics.Generic_Elementary_Functions -- A.5.1; Pure Ada.Real_Time -- D.8; not categorized

The implementation of this package is similar to Ada.Calendar, see that package's discussion.

Any state that the operations need should be contained in the File_Type object; separate state is not needed. However, this package has the same issues as Direct_IO; see the discussion of that package.

GNAT uses a controlled object to clean up files in a package used by Sequential_IO. There is no other state in any of the packages. Janus/Ada uses a small amount of state in a package used by Sequential_IO, this could be moved to Open/Create. There is no other state.

For the same reasons as Direct_IO, this package's categorization is not changed.

This probably could be made pure, but there doesn't seem to be any need.

GNAT uses a controlled object to clean up files in a package used by Stream_IO. There is no other state in any of the packages. Janus/Ada uses a small amount of state in a package used by Stream_IO, this could be moved to Open/Create. There is no other state.

For the same reasons as Direct_IO, this package's categorization is not changed.

This package contains no state, no dependence on non-pure units, no other items that prevent the package from being pure, and does not declare any types that would be a problem for Annex E, so it could be declared pure. But it's large and complex, and many of the operations are not conceptually pure (they do in-place updates), so no change is recommended.

This package is similar to Ada.Strings.Bounded. For similar reasons, no change is recommended; see the discussion on Ada.Strings.Bounded for details.

This package contains a named access-to-subprogram type. AI-366 makes it possible for such packages to be pure. This package contains no state, no dependence on non-pure units, no other items that prevent the package from being pure, and does not declare any types that would be a problem for Annex E. This package should be declared pure.

Since Ada.Strings.Maps is now pure, this package can be as well.

Any implementation will have to depend on Ada.Finalization.

Depends on Ada.Strings.Wide_Maps, see that package's discussion.

This package contains a named access-to-subprogram type. AI-366 makes it possible for such packages to be pure. However, implementations of this package may use access types. Thus, we are not recommending any change here.

Depends on Ada.Strings.Wide_Maps, see that package's discussion.

This package is really an interface to the tasking runtime, and any state needed is either in it or in Suspension_Object. There should be no need for any separate initialization. The routines it depends upon must be able to be called from a pure package (it is perfectly possible to declare or rendezvous with a task in a pure package). Thus, this package should be Preelaborated.

Package Tags has state, so it cannot be pure. That state is generally either set up at link-time (before elaboration) or during the elaboration of tagged types (that is, during the elaboration of other units). In either case, no complex state need be initialized at elaboration time. Thus, this package can be Preelaborated.

GNAT's implementation includes a large number of routines beyond those in the standard definition. Nevertheless, their package could be preelaborated. Janus/Ada uses a 'built-in' implementation of this package, thus the categorization has no impact on the implementation.

This package depends on Ada.Task_Identification and has an access type (with a non-empty pool), so it cannot be pure. The state is either local or in the task runtime; but setting it could require copying the Initial_Value object, which is not allowed for a preelaborated package.

This package is really an interface to the tasking runtime. It has no state of its own. This package should not be pure, because we do not want to insist on support of task_ids in multiple partitions. It couldn't be preelaborated in Ada 95, because of the default initialized constant Null_Task_Id. With appropriate use of pragma Preelaborable_Initialization, this limitation can be eliminated. The package has no state of its own, and the routines it depends upon must be able to be called from a pure package (it is perfectly possible to declare or rendezvous with a task in a pure package). Thus, this package should be Preelaborated.

GNAT's implementation uses a lot of dependencies but no state; we cannot tell if this change would be difficult to implement. Janus/Ada uses a 'built-in' implementation of this package, thus the categorization has no impact on the implementation.

The standard files require state and potentially system subprogram calls to initialize. Therefore, Ada.Text_IO cannot be preelaborated.

Depends on Ada.Text_IO, see the discussion of that unit.

Doesn't need to be pure because it only works on a non-empty storage pool, which is not allowed in a Pure package.

This should be the same as Ada.Text_IO; see the discussion there.

This should be the same as Ada.Wide_Text_IO; see the discussion there.

Can't be pure because it contains an access type that doesn't meet the exceptions of AI-366.

This contains variables Ada_to_Cobol and Cobol_to_Ada in the specification. Thus, it cannot be pure.

Ada 95 already allows this to be pure. It did not require this to be pure because we did not want to require System.Address to be transmitted between partitions. However, all of the existing compiler implementers that responded reported that System was already pure in their compiler (and thus transmitting was supported). Since that is not considered an issue by implementers, we should simply define this package as pure.

Note that making this pure may require some implementations to support explicit 'Read/'Write redefinitions, as AI-366 requires that of any type which has an access type part. It is known that some implementations implement Address as a private type with a full type that is an access type. This is not a problem, as 13.7(36) allows anything to be added to System.

Declares a named access type with a non-empty pool; thus it cannot be pure.

This package's contents and thus categorization are implementation-defined.

It is expected that this package will need to set up the communications channel when it elaborates, thus it cannot be Preelaborable.

This depends on System, which we are changing the categorization of. It also had a permission to be pure in Ada 95; and it does nothing that would be a problem. Thus we require that it be pure.

Doesn't need to be pure because only empty storage pools are allowed in Pure packages.

package Ada.Exceptions is type Exception_Id is private; Null_Id : constant Exception_Id; function Exception_Name(Id : Exception_Id) return String;

package Ada.Exceptions is pragma Preelaborate(Exceptions); type Exception_Id is private; pragma Preelaborable_Initialization (Exception_Id); Null_Id : constant Exception_Id; function Exception_Name(Id : Exception_Id) return String;

type Exception_Occurrence is limited private; type Exception_Occurrence_Access is access all Exception_Occurrence; Null_Occurrence : constant Exception_Occurrence;

type Exception_Occurrence is limited private; pragma Preelaborable_Initialization (Exception_Occurrence); type Exception_Occurrence_Access is access all Exception_Occurrence; Null_Occurrence : constant Exception_Occurrence;

An implementation may add additional implementation-defined declarations to package System and its children. However, it is usually better for the implementation to provide additional functionality via implementation-defined children of System. Package System may be declared pure.

Character_Set : constant Wide_Maps.Wide_Character_Set; -- Contains each Wide_Character value WC such that Characters.Is_Character(WC) is True

package Ada.Task_Identification is type Task_ID is private; Null_Task_ID : constant Task_ID; function "=" (Left, Right : Task_ID) return Boolean;

package Ada.Task_Identification is pragma Preelaborate(Task_Identification); type Task_ID is private; pragma Preelaborable_Initialization (Task_Id); Null_Task_ID : constant Task_ID; function "=" (Left, Right : Task_ID) return Boolean;

with System; with Ada.Task_Identification; -- See C.7.1 package Ada.Dynamic_Priorities is pragma Preelaborate(Dynamic_Priorities);

with Ada.Task_Identification; package Ada.Asynchronous_Task_Control is procedure Hold(T : in Ada.Task_Identification.Task_ID); procedure Continue(T : in Ada.Task_Identification.Task_ID); function Is_Held(T : Ada.Task_Identification.Task_ID) return Boolean; end Ada.Asynchronous_Task_Control;

with Ada.Task_Identification; package Ada.Asynchronous_Task_Control is pragma Preelaborate(Asynchronous_Task_Control); procedure Hold(T : in Ada.Task_Identification.Task_ID); procedure Continue(T : in Ada.Task_Identification.Task_ID); function Is_Held(T : Ada.Task_Identification.Task_ID) return Boolean; end Ada.Asynchronous_Task_Control;