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

[Shark8 <onewingedshark@gmail.com>]

On Wednesday, April 19, 2017 at 1:37:33 AM UTC-6, Dmitry A. Kazakov wrote:
> On 19/04/2017 01:42, Shark8 wrote:
> > On Tuesday, April 18, 2017 at 12:32:34 PM UTC-6, Randy Brukardt wrote:
> >> 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.
> >
> > Are we sure we'd never want that?
> > I imagine that would be an interesting way to do VMs -- essentially
> > transmitting the [contained] memory directly between partitions, right?
> 
> No, so long you don't know what is in the memory. Even considering the 
> case of a shared [distributed] memory pool it cannot be pure.

But of course you know what's in that memory: you put it there. [Well, the compiler; and since accesses are typed of course we know what they are.] -- And a pool[-type] obviously can be pure, as it is only a definition, an interface, if you will.

> E.g. 
> initialization of an object in the shared memory must be done only once, 
> which does not preclude binding of each shared copy/view, like mapping 
> pointers since copies may be located in different virtual address spaces.

Huh?
While 'pointer' and 'access' are forms of indirection, and conceptually the same an access is safer as there is no untyped access. Further, if we use the de facto standard that pointers are an integer (thanks C [/sarc]) then we can recognize that an access needn't be so restricted. Indeed there are cases where it *MUST* be more than an integer, like the case of an access to the value of an unconstrained array-type,as we *MUST* have the bounds.


> > What about a usable-for-anything holder?
> 
> Huh, what about fixing initialization/fixed in the first place. We would 
> not need kludges like holders if any type could have proper constructor 
> and destructor, access types included.

Perhaps, though maybe you should explain what a proper constructor/destructor is -- as I'm pretty sure that C++ style *isn't* what you have in mind.

> >> 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.]
> >
> > That's probably truer than I'd like -- but I guess the question was
> > borne out of playing around w/ pure units and seeing how far I could
> > push the style-guide's instruction "Use pragma Pure where allowed."
> 
> A lot of use cases conflated into single pragma Pure:
> 
> 1. Value/object identity
> 2. Elaboration
> 3. Early evaluation (e.g. compile time, elaboration time)

1. Value/object identity? I'm not sure where you're getting that from., could you elaborate/explain?

3. This is true; it would be nice to have a clear compile-time and elaboration-time distinction.

> It must be reworked from the start, IMO.

Perhaps, though it does quite well in enforcing a lack of state upon the compilation-unit; taken in that manner Pure does a good job as an indicator.