Re: Is there a reason System.Storage_Pools isn't Pure?

["Randy Brukardt" <randy@rrsoftware.com>]

Originally, it was not Pure because it was a child of System, which was not 
Pure. So I can't find any discussion of the merits.

However, Pure packages are automatically Remote_Types packages (that is, 
values of the type can be transmitted between partitions). We'd never want 
that to be the case with a storage pool, so there doesn't seem to be any 
point in it being Pure.

Additionally, the Pure package rules assume that no storage pools can be 
specified for access types (because there aren't rules banning that at 
library-level, and there need to be such rules to prevent hidden state). 
That could be changed, I suppose, but given that a Pure storage pool could 
only be used for a local access type in a Pure package(something that mainly 
exists in ACATS tests), it would be close to useless (or get used for 
back-door state). Note that state has to be strictly prohibited as Pure 
packages are replicated when used in a distributed system (thus each 
partition would have different state, which wouldn't make sense).

IMHO, Pure packages are too restricted to be useful (and not restricted 
enough to be useful when synchronization is involved); it makes sense for 
individual subprograms but not for an entire package. So I recommend only 
trying to make packages Preelaborated. (That's especially true in Ada 2012, 
where limited I/O is possible.) [Distribution might change this thinking; 
I'm only considering stand-alone programs that don't use Annex E.]

                                  Randy.

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:178b6fbc-229b-49fc-8ffb-a5797bfc335f@googlegroups.com...
> Looking at the specification for System.Storage_Pools [RM 13.11(5)] there 
> doesn't seem to be anything that requires the Preelaborate pragma... is 
> there any real reason that it wasn't made a Pure unit?