two questions on allocators

two questions on allocators

[Mehdi Saada]

2.2/3: for an allocator with a subtype indication, the subtype indication shall not specify a null exclusion
why 
type A is access INTEGER;
type B is access not null A; 
type C is access B;
Object_C : C := new B;
is allowed, but not
type A is access INTEGER;
type B is access A; 
type C is access B;
Object_C : C := new not null B; ?? What's the difference ?
_______________________________

If the designated type of the allocator is class-wide, the accessibility level of the type determined by the subtype_indication or qualified_expression shall not be statically deeper than that of the type of the allocator.

-> what means the last "type of the allocator" ? Is it the same than "designed type of the allocator" ?
Does it refer to this situation ? ->
type T is access some_tagged_type'Class;
POINTER : T;
declare
   type CHILD is new some_tagged_type with ...
begin
   POINTER := new CHILD; --illegal
end;

Technical details of this section aren't gonna matter for me any time soon, so that will be all.

Re: two questions on allocators

[Shark8]

On Friday, February 23, 2018 at 1:42:14 PM UTC-7, Mehdi Saada wrote:
> 2.2/3: for an allocator with a subtype indication, the subtype indication shall not specify a null exclusion
> why 
> type A is access INTEGER;
> type B is access not null A; 
> type C is access B;
> Object_C : C := new B;
> is allowed, but not
> type A is access INTEGER;
> type B is access A; 
> type C is access B;
> Object_C : C := new not null B; ?? What's the difference ?

Lots.
In the first one, A is an access to an integer, B is an access to A (with null exclusion), and C is an access to B... so in C/C++ something like int*, int**, and int***, respectively.

The second is the same insofar as the C/C++ analog is concerned; but it's different in that B doesn't exclude Null.

Finally, the phrase "new not null B" is in error, as you cannot say "new not null" in Ada.


> If the designated type of the allocator is class-wide, the accessibility level of the type determined by the subtype_indication or qualified_expression shall not be statically deeper than that of the type of the allocator.
> 
> -> what means the last "type of the allocator" ? Is it the same than "designed type of the allocator" ?

The type of the allocator refers to a concrete instance of System.Storage_Pools.Root_Storage_Pool which can be associated with an access-type via pragma/aspect.

Re: two questions on allocators

[Mehdi Saada]

> Finally, the phrase "new not null B" is in error, as you cannot say "new not null" in Ada.
Here's a simpler exemple ( I think I mixed up A and B, which made my statement meaningless):
type A is access INTEGER;
type B is access not null A;
Object_B : B := new A; --- **
allowed
type A is access INTEGER;
type B is access A;
Object_B : B := new not null A; -- illegal,
but wouldn't that be the same than * ?
Anyway, let's forget it.

> The type of the allocator refers to a concrete instance of System.Storage_Pools.Root_Storage_Pool
I remember... the pool, along with the data it contains shall not outlive its data's tag, makes sense.

Re: two questions on allocators

[AdaMagica]

Am Freitag, 23. Februar 2018 21:42:14 UTC+1 schrieb Mehdi Saada:
> type A is access INTEGER;
> type B is access not null A; 
> type C is access B;
> Object_C : C := new B;
> is allowed, but not
> type A is access INTEGER;
> type B is access A; 
> type C is access B;
> Object_C : C := new not null B; ?? What's the difference ?

As Shark8 has already said, new not null B is a syntax error.

> If the designated type of the allocator is class-wide, the accessibility level of the type determined by the subtype_indication or qualified_expression shall not be statically deeper than that of the type of the allocator.
> 
> -> what means the last "type of the allocator" ? Is it the same than "designed type of the allocator" ?
> Does it refer to this situation ? ->
> type T is access some_tagged_type'Class;
> POINTER : T;
> declare
>    type CHILD is new some_tagged_type with ...
> begin
>    POINTER := new CHILD; --illegal
> end;

The access object is POINTER, its type is T, the designated (not designed) type is some_tagged_type'Class, the type determined by the subtype_indication is Child, as you have declared.

Re: two questions on allocators

[AdaMagica]

Am Freitag, 23. Februar 2018 23:30:06 UTC+1 schrieb Shark8:
> The type of the allocator refers to a concrete instance of System.Storage_Pools.Root_Storage_Pool which can be associated with an access-type via pragma/aspect.

It has nothing to do with storage pools. It's a question of lifetime.

Re: two questions on allocators

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:dfa8abf3-6016-45dc-88de-91f31fac853a@googlegroups.com...
>> Finally, the phrase "new not null B" is in error, as you cannot say "new 
>> not null" in Ada.
> Here's a simpler exemple ( I think I mixed up A and B, which made my 
> statement meaningless):
> type A is access INTEGER;
> type B is access not null A;
> Object_B : B := new A; --- **
> allowed
> type A is access INTEGER;
> type B is access A;
> Object_B : B := new not null A; -- illegal,
> but wouldn't that be the same than * ?
> Anyway, let's forget it.

Naw, let's answer it.

Look in the AARM (4.8(2.a/3) [directly under the rule in question]): "Such 
an uninitialized allocator would necessarily raise Constraint_Error, as the 
default value is null. Also note that the syntax does not allow a 
null_exclusion in an initialized allocator, so it makes sense to make the 
uninitialized case illegal as well."

That is, an access value is default-initialized to the null value. So this 
allocator is just a silly way to write (raise Constraint_Error).

Another such silly way is:
     Object_B : not null B; -- Always raises Constraint_Error.

If you're going to be interested at this level of detail, I suggest looking 
in the AARM, which has various "annotations" explaining rules, and with 
links to the AIs that generated the rules (if they're new). You can usually 
figure out the rules this way. The AARM can be found in most of the usual 
places, in particular on www.ada-auth.org.

                                                 Randy.

Re: two questions on allocators

[Mehdi Saada]

I saw that since I (tried to) read the AARM, but didn't really got it. Now it's ok. If the problem of these null forbidding hypothetic subtypes is that can't have the default null value, why not just require the user to give one ?
I wonder why, the same text I read, coming from you gets clearer ;-)
Those details interest me a lot, as long as it's not Chinese. But the frontier is vague some time, unfortunately.

Re: two questions on allocators

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:55fda761-55f8-4b25-b8ab-0125acf16b05@googlegroups.com...
>I saw that since I (tried to) read the AARM, but didn't really got it. Now 
>it's ok. If the
>problem of these null forbidding hypothetic subtypes is that can't have the 
>default null
>value, why not just require the user to give one ?

That's a different kind of allocator (specifically, initialized allocators 
take qualified expressions). The rule in question is specifically about 
uninitialized allocators.

> I wonder why, the same text I read, coming from you gets clearer ;-)

You have to be the first person to say that ever. :-) Thanks for the ego 
boost!

> Those details interest me a lot, as long as it's not Chinese. But the 
> frontier is vague some time, unfortunately.

Yes, I understand that these notes were written by people who already knew 
the answer, so they don't always make sense (even if I was the one that 
wrote the note originally, they don't always make sense when reading them 
many years later.)

That's one of the reasons for the link to the original AI. That sometimes 
can help (and sometime not!).

                                           Randy.

Re: two questions on allocators

[Robert A Duff]

Mehdi Saada <00120260a@gmail.com> writes:

> I saw that since I (tried to) read the AARM, but didn't really got
> it. Now it's ok. If the problem of these null forbidding hypothetic
> subtypes is that can't have the default null value, why not just require
> the user to give one ?

Don't use "not null"; it's broken as you see.  Instead, do:

    subtype S is T with Predicate => S /= null;

- Bob

Re: two questions on allocators

[Randy Brukardt]

"Robert A Duff" <bobduff@TheWorld.com> wrote in message 
news:wcczi3t6qqh.fsf@TheWorld.com...
> Mehdi Saada <00120260a@gmail.com> writes:
>
>> I saw that since I (tried to) read the AARM, but didn't really got
>> it. Now it's ok. If the problem of these null forbidding hypothetic
>> subtypes is that can't have the default null value, why not just require
>> the user to give one ?
>
> Don't use "not null"; it's broken as you see.  Instead, do:
>
>    subtype S is T with Predicate => S /= null;

??? You'd get the same problem with the allocators (that they always raise 
an exception) with this formulation.

If you did want a subtype to use for an initialized allocator (which the OP 
specifically wasn't using), then

    subtype S is not null T;

works just fine. And this at least is guaranteed to be checked everywhere 
necessary, that's not true for a Dynamic_Predicate (as you know).

Probably in most cases, they are equivalent, but when they are not 
equivalent, it is just because you have pushed static checks to runtime, 
which hardly seems to be an advantage.

                                              Randy.

Re: two questions on allocators

[Dmitry A. Kazakov]

On 01/03/2018 00:37, Randy Brukardt wrote:
> "Robert A Duff" <bobduff@TheWorld.com> wrote in message
> news:wcczi3t6qqh.fsf@TheWorld.com...
>> Mehdi Saada <00120260a@gmail.com> writes:
>>
>>> I saw that since I (tried to) read the AARM, but didn't really got
>>> it. Now it's ok. If the problem of these null forbidding hypothetic
>>> subtypes is that can't have the default null value, why not just require
>>> the user to give one ?
>>
>> Don't use "not null"; it's broken as you see.  Instead, do:
>>
>>     subtype S is T with Predicate => S /= null;
> 
> ??? You'd get the same problem with the allocators (that they always raise
> an exception) with this formulation.
> 
> If you did want a subtype to use for an initialized allocator (which the OP
> specifically wasn't using), then
> 
>      subtype S is not null T;
> 
> works just fine. And this at least is guaranteed to be checked everywhere
> necessary, that's not true for a Dynamic_Predicate (as you know).
> 
> Probably in most cases, they are equivalent, but when they are not
> equivalent, it is just because you have pushed static checks to runtime,
> which hardly seems to be an advantage.

True. Dynamic checks is evil unless a contract. The contract "raise 
Constraint_Error if null" is already there, which makes all exercise 
pointless.

---
As I keep on repeating: constructors, they must be here. There is no way 
to work that fundamental block around. Otherwise we will always be 
running into the same problem that any assignment has a left side, which 
must be come from somewhere and be conform with all constraints 
including ones of the right side.

There is nothing wrong with "not null access" except for lack of 
constructors in Ada.

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

Re: two questions on allocators

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@TheWorld.com> wrote in message 
> news:wcczi3t6qqh.fsf@TheWorld.com...
>> Mehdi Saada <00120260a@gmail.com> writes:
>>
>>> I saw that since I (tried to) read the AARM, but didn't really got
>>> it. Now it's ok. If the problem of these null forbidding hypothetic
>>> subtypes is that can't have the default null value, why not just require
>>> the user to give one ?
>>
>> Don't use "not null"; it's broken as you see.  Instead, do:
>>
>>    subtype S is T with Predicate => S /= null;
>
> ??? You'd get the same problem with the allocators (that they always raise 
> an exception) with this formulation.

I'm not sure which example you're talking about.  There
were several in this thread, and they had enough syntax
errors that I don't know what was intended.

But I don't think so.  3.2.4(31) says that for an uninitialized
allocator, the predicate is checked only if "any subcomponents have
default_expressions", which cannot be the case for an access object.
Am I missing something?  I wrote that wording originally, but it was
a long time ago...

> If you did want a subtype to use for an initialized allocator (which the OP 
> specifically wasn't using), then
>
>     subtype S is not null T;
>
> works just fine. And this at least is guaranteed to be checked everywhere 
> necessary, that's not true for a Dynamic_Predicate (as you know).
> 
> Probably in most cases, they are equivalent, but when they are not 
> equivalent, it is just because you have pushed static checks to runtime, 
> which hardly seems to be an advantage.

"not null" is checked in more places than "Predicate => S /= null".
You might think that means "not null" is safer.  But the problem
with that reasoning is that it means there are cases (as discovered
by the OP) where you can't use "not null".  So if you have:

    type Opt_Thing is access Designated;
    subtype Thing is not null access Opt_Thing;

then there will be cases where you have to use Thing
instead of Opt_Thing, making the code LESS safe.
If you use a predicate, you can use Thing in more cases,
and get more checking.

I can't think of any case in which "not null" is better
than the predicate.  Sometimes they are the same, sometimes
"not null" is worse; hence my recommendation to not use it.

Not null?  Not!  ;-)

- Bob

Re: two questions on allocators

[Shark8]

On Thursday, March 1, 2018 at 4:17:55 PM UTC-7, Robert A Duff wrote:
> 
> I can't think of any case in which "not null" is better
> than the predicate.  Sometimes they are the same, sometimes
> "not null" is worse; hence my recommendation to not use it.

What about interfacing for a library: using "not null" on a parameter means that the body of the program needn't make the manual check for the parameter being null.

Probably with thin-bindings (ie if you're importing rather than exporting) is a good idea, too... then the Ada-side calls can catch it and save you from that madness.

Re: two questions on allocators

[Simon Wright]

Robert A Duff <bobduff@TheWorld.com> writes:

> "not null" is checked in more places than "Predicate => S /= null".
> You might think that means "not null" is safer.

I think I'm going to be terminally confused. I'd rather have to work
round the fact that something was *going* to be checked than be able to
write code (with fingers crossed) using the fact that *in some
circumstances* it might not be.

I recently (discussed here) came across a problem using a predicate
where even Randy wasn't sure whether the predicate check should have
been triggered.

Re: two questions on allocators

[Randy Brukardt]

"Robert A Duff" <bobduff@TheWorld.com> wrote in message 
news:wcctvtzqtb1.fsf@TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Robert A Duff" <bobduff@TheWorld.com> wrote in message
>> news:wcczi3t6qqh.fsf@TheWorld.com...
>>> Mehdi Saada <00120260a@gmail.com> writes:
>>>
>>>> I saw that since I (tried to) read the AARM, but didn't really got
>>>> it. Now it's ok. If the problem of these null forbidding hypothetic
>>>> subtypes is that can't have the default null value, why not just 
>>>> require
>>>> the user to give one ?
>>>
>>> Don't use "not null"; it's broken as you see.  Instead, do:
>>>
>>>    subtype S is T with Predicate => S /= null;
>>
>> ??? You'd get the same problem with the allocators (that they always 
>> raise
>> an exception) with this formulation.
>
> I'm not sure which example you're talking about.  There
> were several in this thread, and they had enough syntax
> errors that I don't know what was intended.
>
> But I don't think so.  3.2.4(31) says that for an uninitialized
> allocator, the predicate is checked only if "any subcomponents have
> default_expressions", which cannot be the case for an access object.
> Am I missing something?  I wrote that wording originally, but it was
> a long time ago...

No, that wording seems wrong. Shouldn't it say "if any subcomponents are 
initialized by default" or something like that? (That is, if the 
subcomponents have defined values.) As it stands, an object initialized by a 
Default_Value aspect (and access types work like that as well) is not 
rechecked.

The rule as it stands means that you have allocated objects that violate 
their predicate. That doesn't seem to be  a good thing. I believe the 
purpose of the rule is avoid checking objects that are completely 
uninitialized (as the result would be random), but there is no reason to 
avoid making the check when the object is initialized-by-default.

>> If you did want a subtype to use for an initialized allocator (which the 
>> OP
>> specifically wasn't using), then
>>
>>     subtype S is not null T;
>>
>> works just fine. And this at least is guaranteed to be checked everywhere
>> necessary, that's not true for a Dynamic_Predicate (as you know).
>>
>> Probably in most cases, they are equivalent, but when they are not
>> equivalent, it is just because you have pushed static checks to runtime,
>> which hardly seems to be an advantage.
>
> "not null" is checked in more places than "Predicate => S /= null".
> You might think that means "not null" is safer.  But the problem
> with that reasoning is that it means there are cases (as discovered
> by the OP) where you can't use "not null".  So if you have:
>
>    type Opt_Thing is access Designated;
>    subtype Thing is not null access Opt_Thing;
>
> then there will be cases where you have to use Thing
> instead of Opt_Thing, making the code LESS safe.
> If you use a predicate, you can use Thing in more cases,
> and get more checking.

??? The only cases where this works is when the object is declared such that 
it violates the predicate and the predicate is NOT checked. An object that 
violates a predicate is a bug, regardless of whether or not it is checked. 
So all this does is hides the detection of a bug -- I can't see any 
advantage to that. If you later use the object without a null check (as 
should be expected), you are going to have a problem.

One reason *not* to use Dynamic_Predicates if an alternative is available is 
because they allow bugs like this. The rule mentioned above needs to be 
fixed *at least* for Static_Predicates, since they are intended to be 
equivalent to constraints, and a constraint would not allow such a 
situation.

> I can't think of any case in which "not null" is better
> than the predicate.  Sometimes they are the same, sometimes
> "not null" is worse; hence my recommendation to not use it.

"not null", as a subtype property, lets the compiler omit access_checks from 
the code. It's possible that the predicate would let the checks be optimized 
away, but that is not a certainty.

> Not null?  Not!  ;-)

So you don't use ranges, either? ;-)

                     Randy.

Re: two questions on allocators

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyinaej0jy.fsf@pushface.org...
> Robert A Duff <bobduff@TheWorld.com> writes:
>
>> "not null" is checked in more places than "Predicate => S /= null".
>> You might think that means "not null" is safer.
>
> I think I'm going to be terminally confused. I'd rather have to work
> round the fact that something was *going* to be checked than be able to
> write code (with fingers crossed) using the fact that *in some
> circumstances* it might not be.

Exactly. The reason for the rule Bob noted was to avoid making predicate 
checks on objects that are completely uninitialized (full of garbage). (Ada 
has the invalid object rules to avoid constraint checks on initially garbage 
values.) But if the object *is* initialized to a known value, that reasoning 
doesn't hold - and Ada *does* require a constraint check on an object with a 
Default_Value aspect. (As noted, access types work like this.) Predicates 
(certainly Static_Predicates) should work the same.

The rule in question was crafted before Default_Value was added to the 
language, and should have taken that into account. Bob would not have "won" 
the argument about the wording of this rule had Default_Value existed then.

> I recently (discussed here) came across a problem using a predicate
> where even Randy wasn't sure whether the predicate check should have
> been triggered.

Yes, Dynamic_Predicate checks are messy. They're primarily associated with 
subtype conversions, when there isn't one there is many problems.

                                   Randy.