!standard 13.11(5) 18-11-15 AI12-0235-1/04 !class Amendment 17-06-09 !status Amendment 1-2012 18-11-15 !status ARG Approved 7-0-0 18-10-21 !status work item 17-06-09 !status received 17-06-09 !priority Low !difficulty Easy !subject System.Storage_Pools should be pure !summary System.Storage_Pools is declared pure, rather than merely preelaborated. !problem It is not possible to define a storage pool in a Pure package as System.Storage_Pools is preelaborated rather than pure. This prevents defining a shared pool type for use in a distributed program. (Note that, due to the prohibition on variables in distributed packages, a pool object cannot itself be shared across partitions.) !proposal (See Summary.) !wording Replace 13.11(5) with: with Ada.Finalization; with System.Storage_Elements; package System.Storage_Pools with Pure, Nonblocking => False is !discussion When Ada 95 was designed, neither Ada.Finalization nor System was declared Pure, so it would have been impossible to declare this package Pure then. Nor were access types allowed. Thus, there is no obvious reason (other than possibly breaking existing implementations) that System.Storage_Pools cannot be Pure. We considered also making the Storage_Pools.Subpools package pure, but felt there was less benefit there, and more likelihood of affecting existing implementations. Note that we do *not* remove the pragma "with Preelaborable_Initialization" in 13.11(6/2), as the default initialization might still call a pure, but non-static function, which is not permitted during initialization of a preelaborated package. This package is Nonblocking => False, as it declares abstract operations that are intended to be overridden. Such operations inherit nonblocking from their ancestor operations, and thus would be incompatible with existing code if set to True (that would prevent the use of potentially blocking operations like I/O, delays, and entry calls in these routines, all of which are allowed in Ada 95, Ada 2005, and Ada 2012). We didn't have to say that for a preelaborable package, as that is the default, but we do have to say it for a Pure package, which defaults to nonblocking. Note that being declared pure seems to promise distribution that isn't actually possible, though we clarify that in the !problem of the AI. !corrigendum 13.11(5) @drepl @xcode<@b Ada.Finalization; @b System.Storage_Elements; @b System.Storage_Pools @b @b Preelaborate(System.Storage_Pools);> @dby @xcode<@b Ada.Finalization; @b System.Storage_Elements; @b System.Storage_Pools @b Pure, Nonblocking =@> False @b> !ASIS No ASIS effect. !ACATS test An ACATS C-Test is needed to check that the new capabilities are supported. !appendix !topic Storage-pools in distributed systems. !reference Ada 202x RM13.11(5); RM13.11.4(3/3) !from Edward Fish 17-05-21 !keywords DSA, storage-pools, purity !discussion In the DSA (Annex E) there are references to accesses across partitions as well as the categorization of library-units (E.2(6/3-6.5/3)); however the package-interface defined in RM13.11 for System.Storage_Pools is Preelaborate as is the Subpools child-package in 13.11.4. Nothing in those packages prevents the contents from being declared pure and it may be advantageous to allow for pools/subpools to be defined in pure units so that subpools may be defined for every partition in the distributed program. (Though it is admitted that you cannot create a pool/subpool in a pure unit, due to the restriction on state, that is quite different than merely defining the pool or subpool type.) *************************************************************** From: Tucker Taft Sent: Tuesday, May 23, 2017 10:05 AM I would agree that it would make sense to shift the categorization of both of these packages from Preelaborate to Pure. At one point Finalization was not declared Pure, but that was changed. Similarly, access types were not permitted in Pure packages at one point, but now they are so long as they have a storage size of zero, so I think both of these packages now can qualify as Pure. *************************************************************** From: Randy Brukardt Sent: Thursday, November 30, 2017 6:50 PM Here's a note for the author of AI12-0235-1 (that would be Tucker): In Ada 2020, changing a package from Preelaborate to Pure potentially has more consequences than just the categorization change, since the values of contract aspects are specified differently for Pure packages by default. For instance, changing: package System.Storage_Pools is pragma Preelaborate (Storage_Pools); ... to: package System.Storage_Pools with Pure is ... is actually the same as: package System.Storage_Pools with Pure, Nonblocking is ... But this latter would be wildly incompatible, as all existing overridings of Allocate/Deallocate would have to be changed to be Nonblocking. (One cannot override a Nonblocking => True subprogram with a Nonblocking => False, lest a dispatching call violate the declaration's promise.) You actually need to explicitly declare: package System.Storage_Pools with Pure, Nonblocking => False is ... in order to avoid any compatibility problem. (Note that AI12-0064-2 only changes library units that require a change currently, which does not include Storage_Pools, since Nonblocking defaults to False -- which is what we want -- for non-pure library units.) I believe there is a similar issue for Global (or will be when it is finished), since it defaults to Global => null for pure units and thus the root primitive operations. *************************************************************** From: Tucker Taft Sent: Wednesday, October 17, 2018 2:07 PM Here is an update to AI12-0235, making System.Storage_Pools pure. I left put Subpools, due to some concerns with implementation impact. *************************************************************** From: Randy Brukardt Sent: Wednesday, October 17, 2018 5:48 PM Thanks. You didn't address the "note for the author of AI12-0235-1" (see my e-mail of November 30th, 2017 in the !appendix). Specifically, A pure package has a default of Nonblocking => True, while a preelaborable package has a default of Nonblocking => False. It would be incompatible for the operations declared in this package (or any existing package which is a root type) to be Nonblocking => True, as that would force all overridings to be Nonblocking => True (which of course would make delays, entry calls, and the like illegal in those overridings). [Important point: remember the reverse isn't true, so an overrider can and should declare their routines Nonblocking => True if that's possible.] So the existing paragraph: with Ada.Finalization; with System.Storage_Elements; package System.Storage_Pools is pragma Preelaborate(System.Storage_Pools); should be replaced by: with Ada.Finalization; with System.Storage_Elements; package System.Storage_Pools with Pure, Nonblocking => False is to be compatible and consistent with other similar units (like Ada.Finalization). I've made an update of the AI with this correction. P.S. Recall that I got John's blessing to use the aspect form in Ada 2020. *************************************************************** From: Tucker Taft Sent: Wednesday, October 17, 2018 7:39 PM Sorry, missed that. Thanks for making the fix. *************************************************************** From: John Barnes Sent: Thursday, October 18, 2018 1:52 AM Note to PS John has taken note of the use of his blessing! ***************************************************************