Version 1.13 of ais/ai-00362.txt

Unformatted version of ais/ai-00362.txt version 1.13
Other versions for file ais/ai-00362.txt

!standard 03.09(06)          05-11-15 AI95-00362/07
!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
!summary
Some predefined packages have categorization added or strengthened.
!problem
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:
Specific problems that have been identified include:
* 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).
!proposal
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.
!wording
Change 3.9(6) to
package Ada.Tags is pragma Preelaborate(Tags); type Tag is private; pragma Preelaborable_Initialization(Tag);
Change 11.4.1(2) to
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;
Change 11.4.1(3) to
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;
Change 13.7(3) to
package System is pragma Pure(System);
Remove the last sentence of 13.7(36).
Change 13.7.1(2) to
package System.Storage_Elements is pragma Pure(Storage_Elements);
Remove 13.7.1(15).
Change A.3.2(2) to
package Ada.Characters.Handling is pragma Pure(Handling);
Change A.4.2(3) to
package Ada.Strings.Maps is pragma Pure(Maps);
Change A.4.6(3) to
package Ada.Strings.Maps.Constants is pragma Pure(Constants);
Add after A.4.7(46):
Pragma Pure is replaced by pragma Preelaborate in Strings.Wide_Maps.Wide_Constants.
Change C.7.1(2) to
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;
Change D.5(3) to
with System; with Ada.Task_Identification; -- See C.7.1 package Ada.Dynamic_Priorities is pragma Preelaborate(Dynamic_Priorities);
Change D.10(3) to
package Ada.Synchronous_Task_Control is pragma Preelaborate(Synchronous_Task_Control);
Change the head of D.11(3) to
with Ada.Task_Identification; package Ada.Asynchronous_Task_Control is pragma Preelaborate(Asynchronous_Task_Control);
!discussion
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.
Standard -- A.1; Pure Ada -- A.2; Pure Ada.Asynchronous_Task_Control -- D.11; not categorized.
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.
Ada.Calendar -- 9.6; not categorized.
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).
Ada.Characters -- A.3.1; Pure Ada.Characters.Handling -- A.3.2; Preelaborate
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.
Ada.Characters.Latin_1 -- A.3.3; Pure Ada.Command_Line -- A.15; Preelaborate
This package has state -- the program's command line -- and thus cannot be pure.
Ada.Decimal -- F.2; Pure Ada.Direct_IO -- A.8.4; not categorized.
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.
Ada.Dynamic_Priorities -- D.5; not categorized
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.
Ada.Exceptions -- 11.4.1; not categorized
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.
Ada.Finalization -- 7.6; Preelaborate
The operations defined by this package are not conceptually pure, so this package should not be pure.
Ada.Float_Text_IO -- A.10.9; not categorized
Depends on Ada.Text_IO; see that unit for discussion.
Ada.Float_Wide_Text_IO -- A.11; not categorized
Depends on Ada.Wide_Text_IO; see that unit for discussion.
Ada.Integer_Text_IO -- A.10.8; not categorized
Depends on Ada.Text_IO; see that unit for discussion.
Ada.Integer_Wide_Text_IO -- A.11; not categorized Ada.Interrupts -- C.3.2; not categorized
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.
Ada.Interrupts.Names -- C.3.2; not categorized
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)).
Ada.Numerics.Elementary_Functions -- A.5.1; Pure Ada.Numerics.Float_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.
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.
Ada.Sequential_IO -- A.8.1; not categorized
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.
Ada.Storage_IO -- A.9; Preelaborate
This probably could be made pure, but there doesn't seem to be any need.
Ada.Streams -- 13.13.1; Pure Ada.Streams.Stream_IO -- A.12.1; not categorized
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 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.
Ada.Strings -- A.4.1; Pure Ada.Strings.Bounded -- A.4.4; Preelaborate
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.
Ada.Strings.Fixed -- A.4.3; Preelaborate
This package is similar to Ada.Strings.Bounded. For similar reasons, no change is recommended; see the discussion on Ada.Strings.Bounded for details.
Ada.Strings.Maps -- A.4.2; Preelaborate
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.
Ada.Strings.Maps.Constants -- A.4.6; Preelaborate
Since Ada.Strings.Maps is now pure, this package can be as well.
Ada.Strings.Unbounded -- A.4.5; Preelaborate
Any implementation will have to depend on Ada.Finalization.
Ada.Strings.Wide_Bounded -- A.4.7; Preelaborate
Depends on Ada.Strings.Wide_Maps, see that package's discussion.
Ada.Strings.Wide_Fixed -- A.4.7; Preelaborate
Depends on Ada.Strings.Wide_Maps, see that package's discussion.
Ada.Strings.Wide_Maps -- A.4.7; Preelaborate
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.
Ada.Strings.Wide_Maps.Wide_Constants -- A.4.7; Preelaborate
Depends on Ada.Strings.Wide_Maps, see that package's discussion.
Ada.Strings.Wide_Unbounded -- A.4.7; Preelaborate
Depends on Ada.Strings.Wide_Maps, see that package's discussion.
Ada.Synchronous_Task_Control -- D.10; not categorized
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.
Ada.Tags -- 3.9; not categorized
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.
Ada.Task_Attributes -- C.7.2; not categorized
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.
Ada.Task_Identification -- C.7.1; not categorized
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.
Ada.Text_IO -- A.10.1; not categorized
The standard files require state and potentially system subprogram calls to initialize. Therefore, Ada.Text_IO cannot be preelaborated.
Ada.Text_IO.Complex_IO -- G.1.3; not categorized
Depends on Ada.Text_IO, see the discussion of that unit.
Ada.Text_IO.Editing -- F.3.3; not categorized
Depends on Ada.Text_IO, see the discussion of that unit.
Ada.Text_IO.Text_Streams -- A.12.2; not categorized
Depends on Ada.Text_IO, see the discussion of that unit.
Ada.Unchecked_Conversion -- 13.9; Pure Ada.Unchecked_Deallocation -- 13.11.2; Preelaborate
Doesn't need to be pure because it only works on a non-empty storage pool, which is not allowed in a Pure package.
Ada.Wide_Text_IO -- A.11; not categorized
This should be the same as Ada.Text_IO; see the discussion there.
Ada.Wide_Text_IO.Complex_IO -- G.1.3; not categorized
This should be the same as Ada.Wide_Text_IO; see the discussion there.
Ada.Wide_Text_IO.Editing -- F.3.4; not categorized
This should be the same as Ada.Wide_Text_IO; see the discussion there.
Ada.Wide_Text_IO.Text_Streams -- A.12.3; not categorized
This should be the same as Ada.Wide_Text_IO; see the discussion there.
Interfaces -- B.2; Pure Interfaces.C -- B.3; Pure Interfaces.C.Pointers -- B.3.2; Preelaborate
Can't be pure because it contains an access type that doesn't meet the exceptions of AI-366.
Interfaces.C.Strings -- B.3.1; Preelaborate
Can't be pure because it contains an access type that doesn't meet the exceptions of AI-366.
Interfaces.COBOL -- B.4; Preelaborate
This contains variables Ada_to_Cobol and Cobol_to_Ada in the specification. Thus, it cannot be pure.
Interfaces.Fortran -- B.5; Pure System -- 13.7; Preelaborate
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.
System.Address_To_Access_Conversions -- 13.7.2; Preelaborate
Declares a named access type with a non-empty pool; thus it cannot be pure.
System.Machine_Code -- 13.8; unspecified
This package's contents and thus categorization are implementation-defined.
System.RPC -- E.5; not categorized
It is expected that this package will need to set up the communications channel when it elaborates, thus it cannot be Preelaborable.
System.Storage_Elements -- 13.7.1; Preelaborate
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.
System.Storage_Pools -- 13.11; Preelaborate
Doesn't need to be pure because only empty storage pools are allowed in Pure packages.
!example
None needed for this proposal.
!corrigendum 3.9(06)
Replace the paragraph:
package Ada.Tags is type Tag is private;
by:
package Ada.Tags is pragma Preelaborate(Tags); type Tag is private; pragma Preelaborable_Initialization(Tag);
!corrigendum 11.4.1(02)
Replace the paragraph:
package Ada.Exceptions is type Exception_Id is private; Null_Id : constant Exception_Id; function Exception_Name(Id : Exception_Id) return String;
by:
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;
!corrigendum 11.4.1(03)
Replace the paragraph:
type Exception_Occurrence is limited private; type Exception_Occurrence_Access is access all Exception_Occurrence; Null_Occurrence : constant Exception_Occurrence;
by:
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;
!corrigendum 13.7(03)
Replace the paragraph:
package System is pragma Preelaborate(System);
by:
package System is pragma Pure(System);
!corrigendum 13.7(36)
Replace the paragraph:
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.
by:
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.
!corrigendum 13.7.1(02)
Replace the paragraph:
package System.Storage_Elements is pragma Preelaborate(System.Storage_Elements);
by:
package System.Storage_Elements is pragma Pure(Storage_Elements);
!corrigendum 13.7.1(15)
Delete the paragraph:
Package System.Storage_Elements may be declared pure.
!corrigendum A.3.2(02)
Replace the paragraph:
package Ada.Characters.Handling is pragma Preelaborate(Handling);
by:
package Ada.Characters.Handling is pragma Pure(Handling);
!corrigendum A.4.2(03)
Replace the paragraph:
package Ada.Strings.Maps is pragma Preelaborate(Maps);
by:
package Ada.Strings.Maps is pragma Pure(Maps);
!corrigendum A.4.6(03)
Replace the paragraph:
package Ada.Strings.Maps.Constants is pragma Preelaborate(Constants);
by:
package Ada.Strings.Maps.Constants is pragma Pure(Constants);
!corrigendum A.4.7(46)
Insert after the paragraph:
Character_Set : constant Wide_Maps.Wide_Character_Set; -- Contains each Wide_Character value WC such that Characters.Is_Character(WC) is True
the new paragraph:
Pragma
Pure is replaced by pragma Preelaborate in Strings.Wide_Maps.Wide_Constants.
!corrigendum C.7.1(02)
Replace the paragraph:
package Ada.Task_Identification is type Task_ID is private; Null_Task_ID : constant Task_ID; function "=" (Left, Right : Task_ID) return Boolean;
by:
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;
!corrigendum D.5(03)
Replace the paragraph:
with System; with Ada.Task_Identification; -- See C.7.1 package Ada.Dynamic_Priorities is
by:
with System; with Ada.Task_Identification; -- See C.7.1 package Ada.Dynamic_Priorities is pragma Preelaborate(Dynamic_Priorities);
!corrigendum D.10(03)
Replace the paragraph:
package Ada.Synchronous_Task_Control is
by:
package Ada.Synchronous_Task_Control is pragma Preelaborate(Synchronous_Task_Control);
!corrigendum D.11(03)
Replace the paragraph:
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;
by:
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;
!ACATS test
ACATS test(s) should be constructed to check that the listed packages are pure and/or preelaborable.
!appendix

Report on making System Pure:

Taft (Sofcheck) : No problem (presuming AI-366 passes).
Dismukes (GNAT): Already Pure.
Cvar (OCS): Already Pure.
Eilers (Irvine): Already Pure.
Nielsen (DDCI): Already Pure.
Brukardt (RRS): Categorization of built-in packages unchecked; effectively Pure.

****************************************************************

From: Robert Dewar
Sent: Saturday, May 14, 2005  8:25 PM

I really think it would be useful if Text_IO were Preelaborate.
I don't buy at all Pascal's concern about difficulty of
implementation. There is nothing to say that the run time
has to be written in Ada, so rules about code generated
in Preealborate units simply don't apply to the run-time,
and an easy implmentation is just to suppress complaints
in this context.

****************************************************************

From: Pascal Leroy
Sent: Sunday, May 15, 2005  2:36 AM

For the record, and despite what the AI seems to imply, I was not
particularly opposed to the notion of making the I/O units Preelaborable.
I was just mentioning some of the implementation work that would be needed
in our case.  It didn't seem terrible, but it seemed sizeable.

We are trying to stay in touch with reality here.  There is nothing that
says that the runtime has to be written in Ada, but if it is, then you
have to cope with the elaboration rules somehow.  Simply suppressing
complaints would in general not work in our technology.  I know because
there are a few places where we do suppress complaints, and it bites us
from time to time because the runtime or the predefined units start in an
environment that is incompletely elaborated, and that wreaks havoc.

The bottom line is that because significant rework was required in our
implementation, and probably in others as well, the ARG felt uncomfortable
with the change.  Note that only DDC/I and IBM Rational replied to the
call for comments on implementation complexity, so it was hard to get a
clear picture of the impact.

****************************************************************

From: Robert Dewar
Sent: Sunday, May 15, 2005  6:20 AM

Well from the GNAT point of view

a) it is out of the question to implement AI-362 in pure Ada. Many of
the units involved rely on elements of the tasking run time that most
certainly need elaboration. Suppressing the diagnostics works fine.
There is no guarantee that if you with a unit in the run time which
is marked pragma Preelaborate that there will be no elaboration
activity, since the behavior of the run time in such respects is out
of scope for the standard (e.g. if the run time was written in C++,
it would be fine to have constructors, since the Ada standard has
nothing to say about constructors).

b) It works just fine in GNAT to simply ignore the associated
diagnostics. Of course it is the case that proper elaboration
is required, but that falls out free if there are non-preelaborate
units in the closure (the fact that they have been with'ed by
preelaborate units is irrelevant for us).

> The bottom line is that because significant rework was required in our
> implementation, and probably in others as well, the ARG felt uncomfortable
> with the change.  Note that only DDC/I and IBM Rational replied to the
> call for comments on implementation complexity, so it was hard to get a
> clear picture of the impact.

I would like to see it at least allowed to make Text_IO preelaborate
as implementatioun permission. You might worry that this causes non-
portability, but in practice if you don't do this, then people end
up using GNAT.IO in any case which is just as non-portable (GNAT.IO
is a subset of Text_IO provided soley because of this preelaborate
problem, which is pretty fierce in practice.

It is quite reasonable to make a basic coding standard that all
packages in an application be preealborate. In the absence of
something like the GNAT model of static elaboration, it is a
reasonable way to ensure freedom from the nightmare of elaboration
problems so common in legacy Ada 83 applications. It is too bad if
a decision like this, which is otherwise reasonable, makes it
impossible to use Text_IO.

****************************************************************

From: Randy Brukardt
Sent: Sunday, May 15, 2005  4:15 PM

...
> a) it is out of the question to implement AI-362 in pure Ada. Many of
> the units involved rely on elements of the tasking run time that most
> certainly need elaboration.

I can believe the last statement, but I don't see how it has anything to do
with AI-362. The tasking system clearly has to be available for Pure and
Preelaborated units (as they both allow the declaration of task objects), so
either they have to be elaborated early (with some sort of permission), or
they have to be completely outside of the Ada system. The whole reason that
we felt comfortable requiring most of the tasking units to be Preelaborated
is that already has to be true.

...
> > The bottom line is that because significant rework was required in our
> > implementation, and probably in others as well, the ARG felt uncomfortable
> > with the change.  Note that only DDC/I and IBM Rational replied to the
> > call for comments on implementation complexity, so it was hard to get a
> > clear picture of the impact.
>
> I would like to see it at least allowed to make Text_IO preelaborate
> as implementatioun permission. You might worry that this causes non-
> portability, but in practice if you don't do this, then people end
> up using GNAT.IO in any case which is just as non-portable (GNAT.IO
> is a subset of Text_IO provided soley because of this preelaborate
> problem, which is pretty fierce in practice.
>
> It is quite reasonable to make a basic coding standard that all
> packages in an application be preealborate. In the absence of
> something like the GNAT model of static elaboration, it is a
> reasonable way to ensure freedom from the nightmare of elaboration
> problems so common in legacy Ada 83 applications. It is too bad if
> a decision like this, which is otherwise reasonable, makes it
> impossible to use Text_IO.

My experience is that because of Text_IO/Stream_IO and Calendar, essentially
nothing can be made Preelaborated. I would have liked to require all of
those to be Preelaborated, but the implementation complexity seems to be
significant in all cases. (I have no idea how to deal with
Current_Input/Current_Output without using initialization at elaboration.)
Anyway, there wasn't sufficient support for a change.

Moreover, it is really late right now. The last time this subject was
discussed (Feb. 2004), you (Robert Dewar) tried to get us to adopt something
like GNAT.IO. That idea was still-born, probably because there was no
agreement on what such a package ought to contain. If you had instead tried
then to push for a Preelaborable Text_IO, we would have had time to properly
study the idea. But it's way too late to do that now. All of the runtimes
that were studied (and there were four) would have had substantial work to
support a preelaborable Text_IO.

My personal feeling is that an Implementation Permission would be even a
harder sell. Moreover, it doesn't seem necessary; the default mode of a
compiler could certainly allow that (certainly Gnat has not been shy about
deviating from the Standard by default when it seems valuable). And I doubt
that there are going to be ACATS tests checking that you *can't* use Text_IO
in a preelaborated unit! I'm certain that any effort spent will be on
ensuring that you *can* use Ada.Exceptions, etc. in a preelaborated unit.

****************************************************************

From: Robert Dewar
Sent: Sunday, May 15, 2005  4:45 PM

>>a) it is out of the question to implement AI-362 in pure Ada. Many of
>>the units involved rely on elements of the tasking run time that most
>>certainly need elaboration.

> I can believe the last statement, but I don't see how it has anything to do
> with AI-362. The tasking system clearly has to be available for Pure and
> Preelaborated units (as they both allow the declaration of task objects), so
> either they have to be elaborated early (with some sort of permission), or
> they have to be completely outside of the Ada system. The whole reason that
> we felt comfortable requiring most of the tasking units to be Preelaborated
> is that already has to be true.

Right, so that just goes to show that it does not matter whether or not
things can be implemented in pure Ada or not. The run time can always be
considered to be completely outside the Ada system, even if it appears
to a casual eye to be implemented in Ada. It is always allowed to implement
the run time in Ada++ where you get to decide the ++ :-)

> My experience is that because of Text_IO/Stream_IO and Calendar, essentially
> nothing can be made Preelaborated. I would have liked to require all of
> those to be Preelaborated, but the implementation complexity seems to be
> significant in all cases. (I have no idea how to deal with
> Current_Input/Current_Output without using initialization at elaboration.)
> Anyway, there wasn't sufficient support for a change.

There is zero implementation difficulty, just ignore categorization errors
in the run-time, there is no RM requirement for such checks, and there is
no requirement that the executable file not have any initialization at
elaboration, since the RM cannot talk about code written in a language
other than Ada.

> Moreover, it is really late right now. The last time this subject was
> discussed (Feb. 2004), you (Robert Dewar) tried to get us to adopt something
> like GNAT.IO. That idea was still-born, probably because there was no
> agreement on what such a package ought to contain. If you had instead tried
> then to push for a Preelaborable Text_IO, we would have had time to properly
> study the idea. But it's way too late to do that now. All of the runtimes
> that were studied (and there were four) would have had substantial work to
> support a preelaborable Text_IO.

For us it would be zero effort

> My personal feeling is that an Implementation Permission would be even a
> harder sell. Moreover, it doesn't seem necessary; the default mode of a
> compiler could certainly allow that (certainly Gnat has not been shy about
> deviating from the Standard by default when it seems valuable).

Hey, I don't know ANY cases where we have deviated from the standard. That's
a serious charge, and should not be thrown around lightly. Please retract
it or say what you mean. We have no deliberate deviations of this kind
from the standard
in GNAT and I am completely shocked that you would charge us
with duplicity (obviously we could not validate if we had known deliberate
deviations from the standard).

Now of course we could have a switch. In fact I guess the most useful form
of that switch would be to allow ANY unit in the run time to be with'ed
from a Pure or Preelaborate unit, but that would not be a deviation from
the standard.

> And I doubt
> that there are going to be ACATS tests checking that you *can't* use Text_IO
> in a preelaborated unit! I'm certain that any effort spent will be on
> ensuring that you *can* use Ada.Exceptions, etc. in a preelaborated unit.

Sorry, we are not in the business of this kind of deliberate deviation. And I
would severely criticize any implementor who took this kind of casual attitude
that it is OK to deviate deliberately since the ACATS does not test for it.

****************************************************************

From: Randy Brukardt
Sent: Sunday, May 15, 2005  5:23 PM

...
> > My personal feeling is that an Implementation Permission would be even a
> > harder sell. Moreover, it doesn't seem necessary; the default mode of a
> > compiler could certainly allow that (certainly Gnat has not been shy about
> > deviating from the Standard by default when it seems valuable).
>
> Hey, I don't know ANY cases where we have deviated from the standard. That's
> a serious charge, and should not be thrown around lightly. Please retract
> it or say what you mean. We have no deliberate deviations of this kind
> from the standard
> in GNAT and I am completely shocked that you would charge us
> with duplicity (obviously we could not validate if we had known deliberate
> deviations from the standard).

Sorry if I confused you, but I was *very* careful in what I said. The
"default mode" certainly doesn't have to be the "standard mode". If a
compiler deviated in "standard mode", that would be a bad thing; but I said
nor meant such a thing. I very carefully said "default mode". And the
"default mode" of GNAT deviates in a number of ways - off the top of my
head:
  * GNAT defaults to its "static elaboration model", which means that it
will not compile some legal, correct Ada programs without a switch;
  * GNAT does not check for integer overflow by default, so some programs do
things not allowed by the standard at runtime (unless a switch is used).

Since GNAT has done these things by default, it certainly be possible to
treat Text_IO as preelaborated by default, and have a switch to get to
"standard mode" (a switch that would be a lot less necessary than -gnatE
or -gnatO). That would get the effect of an Implementation Permission
without having successfully herding the cats of the ARG.

****************************************************************

From: Robert Dewar
Sent: Sunday, May 15, 2005  5:40 PM

> Sorry if I confused you, but I was *very* careful in what I said. The
> "default mode" certainly doesn't have to be the "standard mode". If a
> compiler deviated in "standard mode", that would be a bad thing; but I said
> nor meant such a thing. I very carefully said "default mode". And the
> "default mode" of GNAT deviates in a number of ways - off the top of my
> head:
>   * GNAT defaults to its "static elaboration model", which means that it
> will not compile some legal, correct Ada programs without a switch;
>   * GNAT does not check for integer overflow by default, so some programs do
> things not allowed by the standard at runtime (unless a switch is used).

Oh sure, if you are just making a comment about default options, that's true,
but irrelevant to real users, who set the options they want in their project
files in any case.
>
> Since GNAT has done these things by default, it certainly be possible to
> treat Text_IO as preelaborated by default, and have a switch to get to
> "standard mode" (a switch that would be a lot less necessary than -gnatE
> or -gnatO). That would get the effect of an Implementation Permission
> without having successfully herding the cats of the ARG.

Perhaps, not clear this is a good idea.

****************************************************************

From: Bob Duff
Sent: Sunday, May 15, 2005  5:41 PM

> > My personal feeling is that an Implementation Permission would be even a
> > harder sell. Moreover, it doesn't seem necessary; the default mode of a
> > compiler could certainly allow that (certainly Gnat has not been shy about
> > deviating from the Standard by default when it seems valuable).
                                ^^^^^^^^^^
> Hey, I don't know ANY cases where we have deviated from the standard. That's
> a serious charge, and should not be thrown around lightly.

Note that Randy said "by default".  He's not accusing GNAT of malfeasance.

For example, I believe GNAT omits overflow checks by default.  If you
want standard conformance, you have to say "-gnato" or something.
The gnatmake command, without -gnato, does not properly conform to the
Ada standard.  No big deal, because *with* -gnato (and maybe some other
switches) it *does* conform (modulo some unintended bugs, perhaps).

>...Please retract
> it or say what you mean. We have no deliberate deviations of this kind
> from the standard
> in GNAT and I am completely shocked that you would charge us
> with duplicity (obviously we could not validate if we had known deliberate
> deviations from the standard).

No charge of duplicity here -- just the observation that GNAT's
*standard* mode is not the *default* mode.

> Now of course we could have a switch. In fact I guess the most useful form
> of that switch would be to allow ANY unit in the run time to be with'ed
> from a Pure or Preelaborate unit, but that would not be a deviation from
> the standard.

Agreed.  I think that's all Randy meant.  Plus the fact that you
(AdaCore) can freely choose whether to make this non-standard mode the
default, or not.  I would advise "not".

> Sorry, we are not in the business of this kind of deliberate deviation. And I
> would severely criticize any implementor who took this kind of casual attitude
> that it is OK to deviate deliberately since the ACATS does not test for it.

Hear, hear!  I would say, that if there's a significant chance that some
implementer will violate the rule (either by accident or on purpose),
then an ACATS test is valuable (to encourage portability, at least in
the standard mode).

I will be happy if Text_IO is preelab, or if it's not preelab, in the
RM.  But I don't much like an "implementation permission" which says it
can be preelab or not, according to implementer's whim.  The point of
standards is portability, so I prefer nailing down the semantics, when
possible.

I have no complaint about the fact that "gcc [switches] foo.adb" obeys
the Ada standard, whereas "gcc foo.c" grossly violates the Ada standard!

****************************************************************

From: Robert I. Eachus
Sent: Sunday, May 15, 2005  6:06 PM

>Since GNAT has done these things by default, it certainly be possible to
>treat Text_IO as preelaborated by default, and have a switch to get to
>"standard mode" (a switch that would be a lot less necessary than -gnatE
>or -gnatO). That would get the effect of an Implementation Permission
>without having successfully herding the cats of the ARG.

 Much, much easier to create a 'non-standard' package say, Gnat.Text_IO
that is preelaborated.  This should take just a few minutes if the
source of Text_IO is compatible with pragma Preelaborate.  (Just cut and
paste.)  But this doesn't address the bigger concern that it would be
nice for all programmers to be able to assume that Text_IO could be
called from preelaborated units.

****************************************************************

From: Randy Brukardt
Sent: Sunday, May 15, 2005  6:31 PM

That's what GNAT.IO is about :-)

****************************************************************

Questions? Ask the ACAA Technical Agent