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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2017-04-19 20:50, Shark8 wrote:
> On Wednesday, April 19, 2017 at 1:37:33 AM UTC-6, Dmitry A. Kazakov wrote:

>> 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.

OK, theoretically a pool type can be static. But instances cannot be, so 
it is not much use anyway.

>> 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.

I meant that you must relocate access types pointing inside the 
shared/distributed memory. It is no different to load-time relocation of 
shared libraries.

>>> 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.

In fact I do. C++ has constructors almost right. Ada has nothing but an 
ugly Ada.Finalization hack.

A user-defined constructor is an anonymous subroutine hooked at a 
definite stage of object's initialization. It cannot be called 
explicitly. It cannot be overridden. It is not a primitive operation. It 
can be safely rolled back on exception propagation.

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

There are things with and without identity. E.g. integer value has no 
identity. A task type value has. Stateful objects you refer below 
require identity, obviously. In "X has state S" X is the identity.

> 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.

You mean immutability. Consider a generic unit parametrized by a 
constant value declaring things dependent on the constant. It has 
instances in different states which are pure (not in Ada sense AFAIK) 
but in the sense of being immutable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de