Visibility of Indexing aspects

Visibility of Indexing aspects

[Jere]

I was going through an Ada library and noticed that they
were able to add an indexing aspect to a type in the private
section of a package but have the indexing work for types
declared using the public view of the type.  It's a neat feature,
but I wasn't sure if this was intentional or a GNAT bug?
I searched through sections 13.1 and 4.1.6 of the RM, but no
mention that I could find of the private/public requirements
for the Variable_Indexing and Constant_Indexing aspects.

Is there something I missed in the RM, is this a GNAT bug, or
something else?

Reference example compiled in GCC 8.1:

with Ada.Text_IO; use Ada.Text_IO;

procedure jdoodle is
    package Containers is

      type Container is private;
      
    private

      type Container_Array is array(1..20) of aliased Integer;
      type Container is tagged record
         Data : Container_Array := (others => 0);
      end record
        with Variable_Indexing => Reference;
      
      type Reference_Holder
         (Element : not null access Integer)
      is limited null record
         with Implicit_Dereference => Element;
      
      function Reference
         (Self  : aliased in out Container;
          Index : Positive)
          return Reference_Holder
      is (Element => Self.Data(Index)'Access);
      
    end Containers;
   
    C : aliased Containers.Container;
begin
    for Index in 1 .. 20 loop
        C(Index) := Index;
        Put_Line(Integer'Image(C(Index)));
    end loop;
end jdoodle;

Re: Visibility of Indexing aspects

[Shark8]

On Saturday, July 14, 2018 at 8:18:38 AM UTC-6, Jere wrote:
> I was going through an Ada library and noticed that they
> were able to add an indexing aspect to a type in the private
> section of a package but have the indexing work for types
> declared using the public view of the type.  It's a neat feature,
> but I wasn't sure if this was intentional or a GNAT bug?
> I searched through sections 13.1 and 4.1.6 of the RM, but no
> mention that I could find of the private/public requirements
> for the Variable_Indexing and Constant_Indexing aspects.
> 
> Is there something I missed in the RM, is this a GNAT bug, or
> something else?

I'm not sure what your problem is; it's perfectly fine to attach the predicate in the Private section:
    Package Tmp_2 is
	Type K(<>) is private;
    Private
	Function Valid( Input : String ) Return Boolean;
	Type K is new String
	with Dynamic_Predicate => Valid( String(K) );
	
	Function Valid( Input : String ) Return Boolean is
	    (for all CH of Input => CH /= ' ');
    End Tmp_2;

In fact, the subprograms refereed to in the predicate don't need to be visible at the point of declaration:
    Package Tmp is
	Type K(<>) is private
	with Dynamic_Predicate => Valid( String(K) );
    Private
	Function Valid( Input : String ) Return Boolean;
	Type K is new String;
	
	Function Valid( Input : String ) Return Boolean is
	    (for all CH of Input => CH /= ' ');
    End Tmp;

Re: Visibility of Indexing aspects

[Jere]

On Saturday, July 14, 2018 at 1:04:49 PM UTC-4, Shark8 wrote:
> On Saturday, July 14, 2018 at 8:18:38 AM UTC-6, Jere wrote:
> > I was going through an Ada library and noticed that they
> > were able to add an indexing aspect to a type in the private
> > section of a package but have the indexing work for types
> > declared using the public view of the type.  It's a neat feature,
> > but I wasn't sure if this was intentional or a GNAT bug?
> > I searched through sections 13.1 and 4.1.6 of the RM, but no
> > mention that I could find of the private/public requirements
> > for the Variable_Indexing and Constant_Indexing aspects.
> > 
> > Is there something I missed in the RM, is this a GNAT bug, or
> > something else?
> 
> I'm not sure what your problem is; it's perfectly fine to attach the predicate in the Private section:

I have no problem with it per say, but it runs contrary to how I
have experienced Ada so far, so I wanted to make sure before I
make use of it that it isn't a compiler bug.  This marks the first
time I have ever encountered a situation where the client of a
package can leverage functions from the private part of a package.

In my example, I expected that client had no access to any functionality
of the Container type because the public specification for it was:

    package Containers is

      type Container is private;
     
    private 

There was no mention of being able to index the type (publicly), so it
surprised me that a client using the package could call the index
operation.  If it was intentional, then that was fine, I just wanted to
know because I couldn't find anything in the RM that forbid it, but I 
might have missed something.

Re: Visibility of Indexing aspects

[Dmitry A. Kazakov]

On 2018-07-14 20:29, Jere wrote:

> I have no problem with it per say, but it runs contrary to how I
> have experienced Ada so far,

Yep, aspects are not Ada. Just saying.

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

Re: Visibility of Indexing aspects

[Shark8]

On Saturday, July 14, 2018 at 12:29:44 PM UTC-6, Jere wrote:
> 
> There was no mention of being able to index the type (publicly), so it
> surprised me that a client using the package could call the index
> operation.  If it was intentional, then that was fine, I just wanted to
> know because I couldn't find anything in the RM that forbid it, but I 
> might have missed something.

You do raise a good point though WRT to visibility; it *would* be more consistent with Ada to have a distinction between (eg) publicly indexable and privately indexable types based on where the aspects lay.

OTOH, certain aspects such as (eg) Convention don't need to be public to alter the type in some manner. (Analogous to putting [eg] PRAGMA CONVENTION(FORTRAN, MATRIX) to force the Matrix to be represented in a Column-major manner within the private part.)

I should write this up as an AI for the ARG, if for nothing else than clarification's sake. Thank you for bringing the issue to my attention.

Re: Visibility of Indexing aspects

[Jere]

On Saturday, July 14, 2018 at 7:00:36 PM UTC-4, Shark8 wrote:
> On Saturday, July 14, 2018 at 12:29:44 PM UTC-6, Jere wrote:
> > 
> > There was no mention of being able to index the type (publicly), so it
> > surprised me that a client using the package could call the index
> > operation.  If it was intentional, then that was fine, I just wanted to
> > know because I couldn't find anything in the RM that forbid it, but I 
> > might have missed something.
> 
> You do raise a good point though WRT to visibility; it *would* be more consistent with Ada to have a distinction between (eg) publicly indexable and privately indexable types based on where the aspects lay.
> 
> OTOH, certain aspects such as (eg) Convention don't need to be public to alter the type in some manner. (Analogous to putting [eg] PRAGMA CONVENTION(FORTRAN, MATRIX) to force the Matrix to be represented in a Column-major manner within the private part.)
> 
> I should write this up as an AI for the ARG, if for nothing else than clarification's sake. Thank you for bringing the issue to my attention.

Thanks!
One positive thing about it is that it does allow for safer indexing.
Normally you have to expose a reference type with Implicit_Dereference, 
which exposes access types to your interface and also increases 
design complexity because you may have to figure out how to handle
those reference types potentially outliving the container.  Even though
the issue I raised feels inconsistent, in some ways it might be safer
than the standard way the containers handle indexing because the
reference type is now private and a user cannot save it to a variable
for later use.

Re: Visibility of Indexing aspects

[AdaMagica]

Am Samstag, 14. Juli 2018 16:18:38 UTC+2 schrieb Jere:
> Reference example compiled in GCC 8.1:
> 
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure jdoodle is
>     package Containers is
> 
>       type Container is private;
>       
>     private
> 
>       type Container_Array is array(1..20) of aliased Integer;
>       type Container is tagged record
>          Data : Container_Array := (others => 0);
>       end record
>         with Variable_Indexing => Reference;
>       
>       type Reference_Holder
>          (Element : not null access Integer)
>       is limited null record
>          with Implicit_Dereference => Element;
>       
>       function Reference
>          (Self  : aliased in out Container;
>           Index : Positive)
>           return Reference_Holder
>       is (Element => Self.Data(Index)'Access);
>       
>     end Containers;
>    
>     C : aliased Containers.Container;
> begin
>     for Index in 1 .. 20 loop
>         C(Index) := Index;
>         Put_Line(Integer'Image(C(Index)));
>     end loop;
> end jdoodle;

Where did you get this code from? It's a plain compiler bug. How can a client know the index range?

Re: Visibility of Indexing aspects

[Jere]

On Sunday, July 15, 2018 at 10:41:50 AM UTC-4, AdaMagica wrote:
> Am Samstag, 14. Juli 2018 16:18:38 UTC+2 schrieb Jere:
> > Reference example compiled in GCC 8.1:
> > 
> > with Ada.Text_IO; use Ada.Text_IO;
> > 
> > procedure jdoodle is
> >     package Containers is
> > 
> >       type Container is private;
> >       
> >     private
> > 
> >       type Container_Array is array(1..20) of aliased Integer;
> >       type Container is tagged record
> >          Data : Container_Array := (others => 0);
> >       end record
> >         with Variable_Indexing => Reference;
> >       
> >       type Reference_Holder
> >          (Element : not null access Integer)
> >       is limited null record
> >          with Implicit_Dereference => Element;
> >       
> >       function Reference
> >          (Self  : aliased in out Container;
> >           Index : Positive)
> >           return Reference_Holder
> >       is (Element => Self.Data(Index)'Access);
> >       
> >     end Containers;
> >    
> >     C : aliased Containers.Container;
> > begin
> >     for Index in 1 .. 20 loop
> >         C(Index) := Index;
> >         Put_Line(Integer'Image(C(Index)));
> >     end loop;
> > end jdoodle;
> 
> Where did you get this code from? It's a plain compiler bug. How can a client know the index range?

That's why I started with my original question.  It seems very
odd that it should even be legal.  My intuition screamed bug,
but I couldn't find anything in the RM to say it was illegal.
Is there at least a statement somewhere that specifies the
legality?  I'd rather not go on just what I consider common
sense or my own intuition.

I made the example based off of someone's Ada library on github.

Re: Visibility of Indexing aspects

[AdaMagica]

Am Sonntag, 15. Juli 2018 17:33:04 UTC+2 schrieb Jere:
> That's why I started with my original question.  It seems very
> odd that it should even be legal.  My intuition screamed bug,
> but I couldn't find anything in the RM to say it was illegal.

What about RM 8 Visibility? 8.2(5,7,9) - all these things are not in the visible part.

Re: Visibility of Indexing aspects

[Jere]

On Sunday, July 15, 2018 at 11:22:14 PM UTC-4, AdaMagica wrote:
> Am Sonntag, 15. Juli 2018 17:33:04 UTC+2 schrieb Jere:
> > That's why I started with my original question.  It seems very
> > odd that it should even be legal.  My intuition screamed bug,
> > but I couldn't find anything in the RM to say it was illegal.
> 
> What about RM 8 Visibility? 8.2(5,7,9) - all these things are not in the visible part.

I looked at that, but saw that 8.2(7), which applies in this case, 
specifically leaves out the aspect specification of what is considered 
in/out of the visible part.  It says all things within the type_declaration,
which is not defined to contain the aspect_specification (though the
full_type_declaration does).  Additionally, 8.2 only mentions aspects
in reference to scopes.  I peaked further into section 8.3 but only 
found:

8.3 (23.1/3):
An attribute_definition_clause or an aspect_specification is 
visible everywhere within its scope.

Which sounds like it should be visible even if specified in
the private part (though I am not sure I am reading it right).

The RM seems very unspecific about visibility of aspects outside of
those two spots.  What did I miss?

Re: Visibility of Indexing aspects

[AdaMagica]

Am Dienstag, 17. Juli 2018 02:35:06 UTC+2 schrieb Jere:
> On Sunday, July 15, 2018 at 11:22:14 PM UTC-4, AdaMagica wrote:
> > What about RM 8 Visibility? 8.2(5,7,9) - all these things are not in the visible part.
> 
> I looked at that, but saw that 8.2(7), which applies in this case, 
> specifically leaves out the aspect specification of what is considered 
> in/out of the visible part.  It says all things within the type_declaration,
> which is not defined to contain the aspect_specification (though the
> full_type_declaration does).

Please see 7.3(2/3) - it does!

>  Additionally, 8.2 only mentions aspects
> in reference to scopes.  I peaked further into section 8.3 but only 
> found:
> 
> 8.3 (23.1/3):
> An attribute_definition_clause or an aspect_specification is 
> visible everywhere within its scope.

8.2(10.1/3) The scope of an aspect_specification is identical to the scope of the associated declaration.

Since this is in the private part, it's not in the scope of the private view (which is larger in this case).

> Which sounds like it should be visible even if specified in
> the private part (though I am not sure I am reading it right).

You read it correctly, but forgot to consider the scope.

> The RM seems very unspecific about visibility of aspects outside of
> those two spots.  What did I miss?

The RM tries to be very specific - see above.

Re: Visibility of Indexing aspects

[AdaMagica]

Am Dienstag, 17. Juli 2018 11:46:23 UTC+2 schrieb AdaMagica:
> > I looked at that, but saw that 8.2(7), which applies in this case, 
> > specifically leaves out the aspect specification of what is considered 
> > in/out of the visible part.  It says all things within the type_declaration,
> > which is not defined to contain the aspect_specification (though the
> > full_type_declaration does).
> 
> Please see 7.3(2/3) - it does!

Ah, it seems I misinterpreted your words. The RM syntax for private type declarations contains the aspect specification. The specific example here does not, and this is what you tried to say.

So the scope of the private view is larger than the scope of the full declaration, and the latter only contains the aspect spec. So the scope of the aspect spec is hidden in the private part and thus not visible.

Re: Visibility of Indexing aspects

[Jere]

On Tuesday, July 17, 2018 at 6:11:12 AM UTC-4, AdaMagica wrote:
> Am Dienstag, 17. Juli 2018 11:46:23 UTC+2 schrieb AdaMagica:
> > > I looked at that, but saw that 8.2(7), which applies in this case, 
> > > specifically leaves out the aspect specification of what is considered 
> > > in/out of the visible part.  It says all things within the type_declaration,
> > > which is not defined to contain the aspect_specification (though the
> > > full_type_declaration does).
> > 
> > Please see 7.3(2/3) - it does!
> 
> Ah, it seems I misinterpreted your words. The RM syntax for private type declarations contains the aspect specification. The specific example here does not, and this is what you tried to say.
> 
> So the scope of the private view is larger than the scope of the full declaration, and the latter only contains the aspect spec. So the scope of the aspect spec is hidden in the private part and thus not visible.

I was under the impression that scope and visibility were two different
things.  If I understand you correctly, it sounds like you are saying
that

package Things is
   --One scope
private
   --another scope
end Things;

I was under the impression that it was more like:

package Things is
   --One scope
private
   --same scope but different visibility
end Things;

Also how does this reconcile with:

8.3 (23.1/3):
An attribute_definition_clause or an aspect_specification is
visible everywhere within its scope.

That section makes it sound like aspects created in the private
section are indeed visible in the public section.  

Couple that with the section you mentioned:

8.2(10.1/3) The scope of an aspect_specification is identical to 
the scope of the associated declaration.

which doesn't say that the aspect_specification has to be attached to
the declaration, just associated with it.  A full view is 
associated with the view in the public section.

also makes it sound like the aspect can be placed in the private
part but be the same scope as a declaration in the public part.

Does that clarify my confusion any better?

Re: Visibility of Indexing aspects

[AdaMagica]

Am Freitag, 20. Juli 2018 14:08:11 UTC+2 schrieb Jere:
> I was under the impression that scope and visibility were two different
> things.  If I understand you correctly, it sounds like you are saying
> that
> 
> package Things is
>    --One scope
> private
>    --another scope
> end Things;
> 
> I was under the impression that it was more like:
> 
> package Things is
>    --One scope
> private
>    --same scope but different visibility
> end Things;

The scope of every declaration start with the place of the declaration, so in a package or any declarative region, there are many scopes, some of which are visible, others not.

> Also how does this reconcile with:
> 
> 8.3 (23.1/3):
> An attribute_definition_clause or an aspect_specification is
> visible everywhere within its scope.
> 
> That section makes it sound like aspects created in the private
> section are indeed visible in the public section.

Why do you think so?  

> Couple that with the section you mentioned:
> 
> 8.2(10.1/3) The scope of an aspect_specification is identical to 
> the scope of the associated declaration.

"associated" means the declaration (syntax) in which it appears. This is here in the private part in the full declaration, so it's *not* visible in the public part.

BTW: You should definitely report this severe bug to AdaCore.

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Friday, July 20, 2018 at 11:11:13 AM UTC-5, AdaMagica wrote:
> Am Freitag, 20. Juli 2018 14:08:11 UTC+2 schrieb Jere:
> > I was under the impression that scope and visibility were two different
> > things.  If I understand you correctly, it sounds like you are saying
> > that
> > 
> > package Things is
> >    --One scope
> > private
> >    --another scope
> > end Things;
> > 
> > I was under the impression that it was more like:
> > 
> > package Things is
> >    --One scope
> > private
> >    --same scope but different visibility
> > end Things;
> 
> The scope of every declaration start with the place of the declaration, so in a package or any declarative region, there are many scopes, some of which are visible, others not.
> 
> > Also how does this reconcile with:
> > 
> > 8.3 (23.1/3):
> > An attribute_definition_clause or an aspect_specification is
> > visible everywhere within its scope.
> > 
> > That section makes it sound like aspects created in the private
> > section are indeed visible in the public section.
> 
> Why do you think so?  
> 
> > Couple that with the section you mentioned:
> > 
> > 8.2(10.1/3) The scope of an aspect_specification is identical to 
> > the scope of the associated declaration.
> 
> "associated" means the declaration (syntax) in which it appears. This is here in the private part in the full declaration, so it's *not* visible in the public part.
> 
> BTW: You should definitely report this severe bug to AdaCore.

ARG members, this is why formalizing all the definitions is so important.  (In full support of Jere's point), one would expect “associated” to be transitive.  One would expect the lack of transitivity only with an overtly-defined new narrower term, such as ‘directly associated’, in that:  immediate scope is directly associated with the declarative statement within the private section of the package (and then the visibility would be tied to this immediate scope and thus to this •direct• association.  If Jere's interpretation is to be prohibited, then it must be prohibited via tightening the sloppy definitions, most especially the lack of definitions.

And if any reader thinks that this line of reasoning is incorrect, I offer the rather strong counter-example of AdaCore's current implementation of GNAT as likewise apparently interpreting the _LRM_ according to Jere's interpretation of “associated”, not according to AdaMagica's interpretation of public declarations in partial view ••not being associated•• with private declarations in the full view.

Re: Visibility of Indexing aspects

[Jere]

On Friday, July 20, 2018 at 12:11:13 PM UTC-4, AdaMagica wrote:
> Am Freitag, 20. Juli 2018 14:08:11 UTC+2 schrieb Jere:
> > I was under the impression that scope and visibility were two different
> > things.  If I understand you correctly, it sounds like you are saying
> > that
> > 
> > package Things is
> >    --One scope
> > private
> >    --another scope
> > end Things;
> > 
> > I was under the impression that it was more like:
> > 
> > package Things is
> >    --One scope
> > private
> >    --same scope but different visibility
> > end Things;
> 
> The scope of every declaration start with the place of the declaration, so in a package or any declarative region, there are many scopes, some of which are visible, others not.

I think my confusion comes from being taught that the word scope has a
particular connotation.  Normally a scope exists between two scoping
points ({and } in C/C++, declare/begin and end in Ada and similar
languages).  Based on this discussion though, it seems like Ada has a
different definition that instead starts a an item's specific point
of declaration correct?

> 
> > Also how does this reconcile with:
> > 
> > 8.3 (23.1/3):
> > An attribute_definition_clause or an aspect_specification is
> > visible everywhere within its scope.
> > 
> > That section makes it sound like aspects created in the private
> > section are indeed visible in the public section.
> 
> Why do you think so? 

based on my own confusion mentioned above.  I think I get it now
though.
 
> 
> > Couple that with the section you mentioned:
> > 
> > 8.2(10.1/3) The scope of an aspect_specification is identical to 
> > the scope of the associated declaration.
> 
> "associated" means the declaration (syntax) in which it appears. This is here in the private part in the full declaration, so it's *not* visible in the public part.
> 

Question:  Section 13.1.3 (1/3) says "The declaration with 
the aspect_specification is termed the associated declaration."
In the case of the bugged example I gave, the aspect_specification
was with the full view of the type.  Is that then considered the
declaration of the type, or is just the partial view in the public 
section considered the declaration?  I am assuming the full view
is still considered the declaration.


> BTW: You should definitely report this severe bug to AdaCore.
I'll see if I can figure out a way to word this.  As you can
see, I am not super competent in the RM, so I'm not sure I 
will be able to prove to them it is one.  I'm not a paying
customer (would like to be, but they are out of my price range),
so I normally don't send them bug reports unless I really can
show a verified bug.

Re: Visibility of Indexing aspects

[Jere]

On Friday, July 20, 2018 at 12:11:13 PM UTC-4, AdaMagica wrote:
> Am Freitag, 20. Juli 2018 14:08:11 UTC+2 schrieb Jere:
> > I was under the impression that scope and visibility were two different
> > things.  If I understand you correctly, it sounds like you are saying
> > that
> > 
> > package Things is
> >    --One scope
> > private
> >    --another scope
> > end Things;
> > 
> > I was under the impression that it was more like:
> > 
> > package Things is
> >    --One scope
> > private
> >    --same scope but different visibility
> > end Things;
> 
> The scope of every declaration start with the place of the declaration, so in a package or any declarative region, there are many scopes, some of which are visible, others not.
> 

Side note (not directed as a response.. just needed a reply spot):

I will say the RM would benefit with some visual examples for some 
topics (Scoping, Visibility, Accessibility).  Something like code
snippets with comments showing the various ins/outs of the
particular section above it.  It might even go a long way in 
clarifying some points of the "Heart of Darkness".  I know it
isn't necessarily an easy task and if I was able to discern it all
better, I might take a stab at it (so maybe one day in the future).

Being able to visualize where accessibility levels change 
in some of the more complex examples wold be nice for
example.

Re: Visibility of Indexing aspects

[Jere]

On Friday, July 20, 2018 at 6:23:02 PM UTC-4, Jere wrote:
> 
> Being able to visualize where accessibility levels change 
> in some of the more complex examples wold be nice for
> example.

Sorry, said the wrong thing.  I meant being able to see 
how the accessibility checks are calculated in complex
examples.  I was typing in haste.

Re: Visibility of Indexing aspects

[J-P. Rosen]

Le 21/07/2018 à 00:23, Jere a écrit :
> I will say the RM would benefit with some visual examples for some 
> topics (Scoping, Visibility, Accessibility).  Something like code
> snippets with comments showing the various ins/outs of the
> particular section above it.  It might even go a long way in 
> clarifying some points of the "Heart of Darkness".  I know it
> isn't necessarily an easy task and if I was able to discern it all
> better, I might take a stab at it (so maybe one day in the future).

The 83 reference manual had more examples, and it was a deliberate
decision to have less examples from 95 on. The rationale is that the RM
is for precise definitions, lawyers and compiler writers, and that
examples bring nothing formally except possible errors.

The RM is definitely not for learning the language. BTW, have you seen
anybody learning Fortran or C++ from its standard? In a sense, the wide
availability of the RM made it too easy too look at for beginners!

OTOH, if you want to write an "RM explained and commented" book, you are
very welcome to do so, it would certainly be useful.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Visibility of Indexing aspects

[AdaMagica]

Am Samstag, 21. Juli 2018 00:07:01 UTC+2 schrieb Jere:
> > BTW: You should definitely report this severe bug to AdaCore.
> I'll see if I can figure out a way to word this.  As you can
> see, I am not super competent in the RM, so I'm not sure I 
> will be able to prove to them it is one.  I'm not a paying
> customer (would like to be, but they are out of my price range),
> so I normally don't send them bug reports unless I really can
> show a verified bug.

No need of proof that this is a bug. I sent in many reports, most of them indeed were bugs, a few not. I learned to read the RM in this way. (I was a supported user then, so AdaCore promptly answered any report with interesting discussions - and I remember extremely rare events when I was right and they were wrong - mostly it was the other way round and I learned to read the RM word by word. But I don't claim to be a language lawyer, I never did.)

If you want to substantiate your report, just add the RM references appearing in this discussion. But I think just the ovservation that something hidden in the private part is useable from outside should be sufficient to indicate that there is a severe bug in the implementation (of the RM, i.e. the compiler GNAT).

And there is still the old Dewar rule: The RM does not say nonsense. If it seems so, the interpretation is wrong.

Re: Visibility of Indexing aspects

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:dbc94806-dbf9-408d-b8ad-3a159eb85b24@googlegroups.com...
...
> Question:  Section 13.1.3 (1/3) says "The declaration with
> the aspect_specification is termed the associated declaration."
> In the case of the bugged example I gave, the aspect_specification
> was with the full view of the type.  Is that then considered the
> declaration of the type, or is just the partial view in the public
> section considered the declaration?  I am assuming the full view
> is still considered the declaration.

They're two separate-but-related declarations. You can tell if something is 
a declaration by looking at the name of its syntax. If the syntax includes 
"_declaration",  then it's a declaration. And since we have 
private_type_declaration and full_type_declaration, they're both 
declarations. (See RM 3.1 for the more formal definitions.)

There are implicit declarations as well, of course, but they don't have 
anything to do with this particular question.

                                         Randy.

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Monday, July 23, 2018 at 10:32:04 PM UTC-5, Randy Brukardt wrote:
> "Jere" wrote in message 
> news:dbc94806-dbf9-408d-b8ad-3a159eb85b24@googlegroups.com...
> ...
> > Question:  Section 13.1.3 (1/3) says "The declaration with
> > the aspect_specification is termed the associated declaration."
> > In the case of the bugged example I gave, the aspect_specification
> > was with the full view of the type.  Is that then considered the
> > declaration of the type, or is just the partial view in the public
> > section considered the declaration?  I am assuming the full view
> > is still considered the declaration.
> 
> They're two separate-but-related declarations. You can tell if something is 
> a declaration by looking at the name of its syntax. If the syntax includes 
> "_declaration",  then it's a declaration. And since we have 
> private_type_declaration and full_type_declaration, they're both 
> declarations. (See RM 3.1 for the more formal definitions.)
> 
> There are implicit declarations as well, of course, but they don't have 
> anything to do with this particular question.

But where is “associated” (as quoted from the _LRM_) defined as clearly not meaning “related” (as quoted from Randy's reply)?

AdaMagica overtly claims (and Randy less directly seems to affirm) that only the private declaration of Container is “associated” in the _LRM_.  Conversely, Randy directly claims that the public declaration of Container is “related” (but presumably not “associated”).  Unless these “associated” and “related” terms are given definitions overtly in the _LRM_ (or at least illuminating-color commentary in the _AARM_), then relying the commonfolk English dictionary definitions of “associated” and “related” do not give definitions that definitively say that the public declaration of Container is “related” but not “associated” to the private declaration of Container.  (This is what I mean a few replies ago about ‘sloppy definitions’.)

And if this ambiguity (that clearly AdaCore interpreted differently than via this thread's logic) is resolved by making the OP's code illegal, then what would be the adjustment to the OP's code to attain that intended & evoked feature (that would be otherwise removed)?  Would this be the replacement to keep the Reference et. al. private?
with Ada.Text_IO; use Ada.Text_IO; 
with Ada.Text_IO; use Ada.Text_IO; 

procedure jdoodle is 
    package Containers is 

      type Container is private
        with Variable_Indexing => Reference;
OR
      type Container is private record
        with Variable_Indexing => Reference;
OR
      type Container is private tagged record
        with Variable_Indexing => Reference;
      
    private 

      type Container_Array is array(1..20) of aliased Integer; 
      type Container is tagged record 
         Data : Container_Array := (others => 0); 
      end record;
      
      type Reference_Holder 
         (Element : not null access Integer) 
      is limited null record 
         with Implicit_Dereference => Element; 
      
      function Reference 
         (Self  : aliased in out Container; 
          Index : Positive) 
          return Reference_Holder 
      is (Element => Self.Data(Index)'Access); 
      
    end Containers; 
    
    C : aliased Containers.Container; 
begin 
    for Index in 1 .. 20 loop 
        C(Index) := Index; 
        Put_Line(Integer'Image(C(Index))); 
    end loop; 
end jdoodle;

Re: Visibility of Indexing aspects

[Randy Brukardt]

I'm not even going to try to figure out what you are talking about. Perhaps 
a few facts would help:

A private_type_declaration and a full_type_declaration are both 
declarations, with their own visibility. But they declare different  *views* 
of the *same* entity (a type in this case). Ada has many such pairs of 
declarations (usually, the second one is called a completion, see 3.11.1). 
Type aspects apply to the type, never the view, so the value is the same for 
all views. There are some aspects which whether or not you can use them 
depends on whether they are visible (given on the private type) -- but the 
*value* of the aspect is the same for all views (it just might be hidden). 
This model is carefully explained in 13.1 and 13.1.1.

> that clearly AdaCore interpreted differently than via this thread's logic

It's far more likely that they just made a mistake or omission. Let me give 
you a bit of reality: 20-25% of new ACATS tests fail when run with the 
latest compiler. (Those numbers hold for every Ada compiler that I've ever 
tried.) Ada is simply too large for any implementer to even remember to 
enforce every rule and implement every possible combination. The reason that 
the ACATS is so important to Ada is that it provides at least a base line of 
known-good tests that substantially reduce these.

Real Ada compiler development tends to be a slog through making ACATS and 
other in-house tests work while being constantly interrupted with important 
bugs to fix from one's customers. And then suddenly your boss and/or 
customers are expecting a new version promised for July (OK, a bit personal 
here :-) and you need it done yesterday. It's real easy in those conditions 
to simply forget to do something (like apply visibility to an indexing 
aspect); if the mistake doesn't show up in a test, it's likely to go 
undetected until someone trips over it. That sort of thing is rarely an 
intentional decision (although the occassional shortcut can happen, too, 
where something is intentionally left unimplemented).

                                      Randy.



"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:8720f70a-59b1-4297-b2fc-78804ec88b7b@googlegroups.com...
On Monday, July 23, 2018 at 10:32:04 PM UTC-5, Randy Brukardt wrote:
> "Jere" wrote in message
> news:dbc94806-dbf9-408d-b8ad-3a159eb85b24@googlegroups.com...
> ...
> > Question:  Section 13.1.3 (1/3) says "The declaration with
> > the aspect_specification is termed the associated declaration."
> > In the case of the bugged example I gave, the aspect_specification
> > was with the full view of the type.  Is that then considered the
> > declaration of the type, or is just the partial view in the public
> > section considered the declaration?  I am assuming the full view
> > is still considered the declaration.
>
> They're two separate-but-related declarations. You can tell if something 
> is
> a declaration by looking at the name of its syntax. If the syntax includes
> "_declaration",  then it's a declaration. And since we have
> private_type_declaration and full_type_declaration, they're both
> declarations. (See RM 3.1 for the more formal definitions.)
>
> There are implicit declarations as well, of course, but they don't have
> anything to do with this particular question.

But where is "associated" (as quoted from the _LRM_) defined as clearly not 
meaning "related" (as quoted from Randy's reply)?

AdaMagica overtly claims (and Randy less directly seems to affirm) that only 
the private declaration of Container is "associated" in the _LRM_. 
Conversely, Randy directly claims that the public declaration of Container 
is "related" (but presumably not "associated").  Unless these "associated" 
and "related" terms are given definitions overtly in the _LRM_ (or at least 
illuminating-color commentary in the _AARM_), then relying the commonfolk 
English dictionary definitions of "associated" and "related" do not give 
definitions that definitively say that the public declaration of Container 
is "related" but not "associated" to the private declaration of Container. 
(This is what I mean a few replies ago about 'sloppy definitions'.)

And if this ambiguity (that clearly AdaCore interpreted differently than via 
this thread's logic) is resolved by making the OP's code illegal, then what 
would be the adjustment to the OP's code to attain that intended & evoked 
feature (that would be otherwise removed)?  Would this be the replacement to 
keep the Reference et. al. private?
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Text_IO; use Ada.Text_IO;

procedure jdoodle is
    package Containers is

      type Container is private
        with Variable_Indexing => Reference;
OR
      type Container is private record
        with Variable_Indexing => Reference;
OR
      type Container is private tagged record
        with Variable_Indexing => Reference;

    private

      type Container_Array is array(1..20) of aliased Integer;
      type Container is tagged record
         Data : Container_Array := (others => 0);
      end record;

      type Reference_Holder
         (Element : not null access Integer)
      is limited null record
         with Implicit_Dereference => Element;

      function Reference
         (Self  : aliased in out Container;
          Index : Positive)
          return Reference_Holder
      is (Element => Self.Data(Index)'Access);

    end Containers;

    C : aliased Containers.Container;
begin
    for Index in 1 .. 20 loop
        C(Index) := Index;
        Put_Line(Integer'Image(C(Index)));
    end loop;
end jdoodle; 

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Wednesday, July 25, 2018 at 12:37:53 AM UTC-5, Randy Brukardt wrote:
> I'm not even going to try to figure out what you are talking about. Perhaps 
> a few facts would help:
> 
> A private_type_declaration and a full_type_declaration are both 
> declarations, with their own visibility. But they declare different  *views* 
> of the *same* entity (a type in this case). Ada has many such pairs of 
> declarations (usually, the second one is called a completion, see 3.11.1). 
> Type aspects apply to the type, never the view, so the value is the same for 
> all views. There are some aspects which whether or not you can use them 
> depends on whether they are visible (given on the private type) -- but the 
> *value* of the aspect is the same for all views (it just might be hidden). 
> This model is carefully explained in 13.1 and 13.1.1.
> 
> > that clearly AdaCore interpreted differently than via this thread's logic
> 
> It's far more likely that they just made a mistake or omission. Let me give 
> you a bit of reality: 20-25% of new ACATS tests fail when run with the 
> latest compiler. (Those numbers hold for every Ada compiler that I've ever 
> tried.) Ada is simply too large for any implementer to even remember to 
> enforce every rule and implement every possible combination. The reason that 
> the ACATS is so important to Ada is that it provides at least a base line of 
> known-good tests that substantially reduce these.
> 
> Real Ada compiler development tends to be a slog through making ACATS and 
> other in-house tests work while being constantly interrupted with important 
> bugs to fix from one's customers. And then suddenly your boss and/or 
> customers are expecting a new version promised for July (OK, a bit personal 
> here :-) and you need it done yesterday. It's real easy in those conditions 
> to simply forget to do something (like apply visibility to an indexing 
> aspect); if the mistake doesn't show up in a test, it's likely to go 
> undetected until someone trips over it. That sort of thing is rarely an 
> intentional decision (although the occassional shortcut can happen, too, 
> where something is intentionally left unimplemented).
> 
>                                       Randy.
> 
> 
> 
> "Dan'l Miller" wrote in message 
> news:8720f70a-59b1-4297-b2fc-78804ec88b7b@googlegroups.com...
> On Monday, July 23, 2018 at 10:32:04 PM UTC-5, Randy Brukardt wrote:
> > "Jere" wrote in message
> > news:dbc94806-dbf9-408d-b8ad-3a159eb85b24@googlegroups.com...
> > ...
> > > Question:  Section 13.1.3 (1/3) says "The declaration with
> > > the aspect_specification is termed the associated declaration."
> > > In the case of the bugged example I gave, the aspect_specification
> > > was with the full view of the type.  Is that then considered the
> > > declaration of the type, or is just the partial view in the public
> > > section considered the declaration?  I am assuming the full view
> > > is still considered the declaration.
> >
> > They're two separate-but-related declarations. You can tell if something 
> > is
> > a declaration by looking at the name of its syntax. If the syntax includes
> > "_declaration",  then it's a declaration. And since we have
> > private_type_declaration and full_type_declaration, they're both
> > declarations. (See RM 3.1 for the more formal definitions.)
> >
> > There are implicit declarations as well, of course, but they don't have
> > anything to do with this particular question.
> 
> But where is "associated" (as quoted from the _LRM_) defined as clearly not 
> meaning "related" (as quoted from Randy's reply)?
> 
> AdaMagica overtly claims (and Randy less directly seems to affirm) that only 
> the private declaration of Container is "associated" in the _LRM_. 
> Conversely, Randy directly claims that the public declaration of Container 
> is "related" (but presumably not "associated").  Unless these "associated" 
> and "related" terms are given definitions overtly in the _LRM_ (or at least 
> illuminating-color commentary in the _AARM_), then relying the commonfolk 
> English dictionary definitions of "associated" and "related" do not give 
> definitions that definitively say that the public declaration of Container 
> is "related" but not "associated" to the private declaration of Container. 
> (This is what I mean a few replies ago about 'sloppy definitions'.)
> 
> And if this ambiguity (that clearly AdaCore interpreted differently than via 
> this thread's logic) is resolved by making the OP's code illegal, then what 
> would be the adjustment to the OP's code to attain that intended & evoked 
> feature (that would be otherwise removed)?  Would this be the replacement to 
> keep the Reference et. al. private?
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure jdoodle is
>     package Containers is
> 
>       type Container is private
>         with Variable_Indexing => Reference;
> OR
>       type Container is private record
>         with Variable_Indexing => Reference;
> OR
>       type Container is private tagged record
>         with Variable_Indexing => Reference;
> 
>     private
> 
>       type Container_Array is array(1..20) of aliased Integer;
>       type Container is tagged record
>          Data : Container_Array := (others => 0);
>       end record;
> 
>       type Reference_Holder
>          (Element : not null access Integer)
>       is limited null record
>          with Implicit_Dereference => Element;
> 
>       function Reference
>          (Self  : aliased in out Container;
>           Index : Positive)
>           return Reference_Holder
>       is (Element => Self.Data(Index)'Access);
> 
>     end Containers;
> 
>     C : aliased Containers.Container;
> begin
>     for Index in 1 .. 20 loop
>         C(Index) := Index;
>         Put_Line(Integer'Image(C(Index)));
>     end loop;
> end jdoodle;

My point is this:  the work-around/fix
1) to the so-called “severe bug” of implicitly leaking private view's declarations into the public view of a package
is to
2) force the programmer to move the formerly-private declarations to be public declarations in that package.

Looking at it from a software engineering perspective** (of the package designer and the user of the package) instead of the compiler implementer, ••forcing the programmer•• to publicly textually leak intended-to-be-private declarations of his/her design is not any better than the •compiler• doing just the minimal amount of clever promotion of just the right pieces of private aspects to public.  #1 is deemed a so-called “severe bug” when the compiler actually successfully cleverly accomplishes the beneficial use-case of hiding of Reference et. al. in the private view, but #2 is admirably ‘working as designed’ when the programmer lets far more* private guts hang out in the public view of the package for all sorts of misuse/abuse by the users of the package.

* far more detail: all of {Reference, Reference_Holder, Container_Array, ...}

In the end, the intended use-case of privately hiding all of {Reference, Reference_Holder, Container_Array, ...} from misuse by users of the public interface of the package is •not• accomplished by option #2 nor by the _LRM_ as currently written.  At least #1's/OP's/GNAT's misinterpretation of the _LRM_ actually accomplished the use-case of inhibiting the misuse/abuse of Reference et. al.  Complying with the _LRM_ as currently written/designed is arguably worse than the so-called “severe bug”, when looked at from the discipline of software engineering** instead of a compiler writer (or language lawyer mechanically turning the crank of the _LRM_'s language).

** as Jean Ichbiah and HOLWG did

Effectively saying ‘Bah humbug’ to software engineering's intended use-case (of privately hiding all of {Reference, Reference_Holder, Container_Array, ...} from misuse by users of the public interface of the package) is arguably worse than the so-called “severe bug”.

Re: Visibility of Indexing aspects

[AdaMagica]

Much ado about nothing.

The writer of this code erroneously put things in the private part which should have been public. There is a compiler bug leaking from privacy which seduced the writer into thinking that his wrong code is correct.

The RM is very precise about this, see the references in this thread.

Love's Labours Lost with any further discussion.

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Wednesday, July 25, 2018 at 2:58:44 PM UTC-5, AdaMagica wrote:
> Much ado about nothing.
> 
> The writer of this code erroneously put things in the private part which should have been public. There is a compiler bug leaking from privacy which seduced the writer into thinking that his wrong code is correct.
> 
> The RM is very precise about this, see the references in this thread.
> 
> Love's Labours Lost with any further discussion.

In other words, I made an insightful good point about Ada failing (in that vicinity) to live up to a key portion of its core mission/reason-for-existence from Day One:  the ability to keep private portions of a design private by not forcing public declarations of portions of the design that the designer overtly intends to be kept private.  The response to my insightful good point about Ada embarrassingly failing (in this portion) to live up to one of its fundamental goals (i.e., encapsulation):  Shut it down!  Shut it down!  Speak no more about this topic!  Bury it!  Nothing to see here; move along!
https://www.youtube.com/watch?v=pdFl__NlOpA&frags=pl%2Cwn

This so-called “severe compiler bug” is a highly useful software-engineering usecase of keeping private portions of the design private instead of forcibly dragging source code up to public for no good reason in the design.  The gratuitous publicizing of those OP's private declarations of {Reference, Reference_Holder, Container_Array, ...} opens those gratuitously-publicized declarations up to misuse and abuse by users of the package, in contravention of Steelman requirements 3-5A and 3-5B.

The designer of OP's package wants to evoke the Variable_Indexing for users of the package without permitting the users of the package to directly use/misuse/abuse {Reference, Reference_Holder, Container_Array, ...}.

Steelman 3-5A clearly states “An encapsulation may contain declarations of ••anything•• (including the data elements and operations comprising a type) that is definable in programs.”  Variable_Indexing clearly is a set of operations comprising a type.

Steelman 3-5B clearly states “An encapsulation may be used to inhibit external access to implementation properties of the definition. In particular, it shall be possible to prevent external reference to ••any declaration•• within the encapsulation including automatically defined operations such as type conversions and equality. Definitions that are made within an encapsulation and are ••externally accessible•• may be renamed before use outside the encapsulation.”

So the question is:  how does the _LRM_ live up to Steelman 3-5B's requirement for “•any• declaration” for “automatically defined operations” (e.g., Variable_Indexing) to be made “•externally accessible•” in the public part of the package by being “renamed before use outside” that private part of the package?  It seems that OP's/GNAT's “severe bug” comes far closer to living up to the letter & spirit of Steelman 3-5B's explicit demand there than the current wording of the _LRM_ that seems to force those private declarations of {Reference, Reference_Holder, Container_Array, ...} to be gratuitously publicized.

The _LRM_'s forcing of {Reference, Reference_Holder, Container_Array, ...} to be public declarations instead of OP's private declarations seems to be itself a crystal-clear “severe noncompliance” with Steelman 3-5A's “•any• declaration … including •automatically defined• operations” intersecting with Steelman 3-5B's “••any declaration•• … including automatically defined operations … made … ••externally accessible•• ”.

Re: Visibility of Indexing aspects

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:3eebe2fb-f066-4248-9b2f-1db32497fd82@googlegroups.com...
On Wednesday, July 25, 2018 at 2:58:44 PM UTC-5, AdaMagica wrote:
>> Much ado about nothing.
>>
>> The writer of this code erroneously put things in the private part which
>> should have been public. There is a compiler bug leaking from privacy
>>which seduced the writer into thinking that his wrong code is correct.
>>
>> The RM is very precise about this, see the references in this thread.
>>
>> Love's Labours Lost with any further discussion.
>
>In other words, I made an insightful good point ...

Sounds like babble to me. What's used by the client has to be public, 
period.

...
>The _LRM_'s forcing of {Reference, Reference_Holder, Container_Array, ...} 
>to be public declarations ...

...is perfectly fine -- there's nothing wrong or dangerous with using them 
directly. Indeed, "indexing" is just a shorthand for a longer call involving 
Reference -- you're always allowed to make the longer call, just like you 
are allowed to put in .all even if you could have omitted it. We went to 
substantial lengths to ensure that you can't keep a reference value longer 
than the existence of the return object from Reference -- regardless of how 
you use the package. (Telling people not to do something is never an 
effective technique for safety!)

If you have declarations that *can't* be used directly, then put them into 
the private part. But you're never supposed to be getting a half-and-half 
situation.

                                           Randy.

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Wednesday, July 25, 2018 at 7:12:24 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:3eebe2fb-f066-4248-9b2f-1db32497fd82@googlegroups.com...
> On Wednesday, July 25, 2018 at 2:58:44 PM UTC-5, AdaMagica wrote:
> >> Much ado about nothing.
> >>
> >> The writer of this code erroneously put things in the private part which
> >> should have been public. There is a compiler bug leaking from privacy
> >>which seduced the writer into thinking that his wrong code is correct.
> >>
> >> The RM is very precise about this, see the references in this thread.
> >>
> >> Love's Labours Lost with any further discussion.
> >
> >In other words, I made an insightful good point ...
> 
> Sounds like babble to me. What's used by the client has to be public, 
> period.
> 
> ...
> >The _LRM_'s forcing of {Reference, Reference_Holder, Container_Array, ...} 
> >to be public declarations ...
> 
> ...is perfectly fine -- there's nothing wrong or dangerous with using them 
> directly. Indeed, "indexing" is just a shorthand for a longer call involving 
> Reference -- you're always allowed to make the longer call

Yeah, unyieldingly demanding that unnecessary feature is the root-cause of the violation of Steelman 3-5B detailed far below.

In effect as explained in detail far below, Steelman 3-5F is requiring the ability to optionally have this scenario in addition to _AARM_:2016's ¶22/3 of §4.1.6 on page 189, by burying {Find, Data} in private view with only IB and its Variable_Indexing aspect in public view:

from outside the package:
Find (IB,"pear").Data.all := Element'(...); -- illegal
IB.Find ("pear").Data.all := Element'(...); -- illegal
IB.Find ("pear") := Element'(...); -- illegal
IB ("pear") := Element'(...); -- allowed
IB ("pear").Data.all := Element'(...); -- illegal

> , just like you 
> are allowed to put in .all even if you could have omitted it. We went to 
> substantial lengths to ensure that you can't keep a reference value longer 
> than the existence of the return object from Reference -- regardless of how 
> you use the package. (Telling people not to do something is never an 
> effective technique for safety!)
> 
> If you have declarations that *can't* be used directly, then put them into 
> the private part. But you're never supposed to be getting a half-and-half 
> situation.
> 
>                                            Randy.

So which part of the definition of “declaration” does each member d of {Reference, Reference_Holder, Container_Array} not satisfy with respect to Steelman 3-5B's “In particular, it shall be possible to prevent external reference to ••any declaration•• within the encapsulation including automatically defined operations …”? Or is it that each d fails to satisfy the definition of “any”?  Because the only way to satisfy Steelman 3-5B and still have the _LRM_'s current wording hold regarding all of {Variable_Indexing aspect, Reference, Reference_Holder, Container_Array} absolutely being in the public view is for somehow someone to demonstrate how Reference isn't “any declaration”, Reference_Holder isn't “any declaration”, and Container_Array isn't “any declaration”.

It does quite clearly say “any declaration” there in Steelman 3-5B.  Indeed, 3-5B even wisely predicts the precise situation of implicitly/automatically compiler-generated operations (e.g., the Variable_Indexing aspect) in the “including automatically defined operations”.  It seems that Steelman 3-5B is overtly requiring the ability to declare Variable_Indexing in the public part of the package with {Reference, Reference_Holder, Container_Array} in the private part of the package, due to:
1) Variable_Indexing be 3-5B's “including automatically-defined operations”;
2) Reference clearly fully satisfies the definition of 3-5B's “any declaration”;
3) Reference_Holder clearly fully satisfies the definition of 3-5B's “any declaration”;
4) Container_Array clearly fully satisfies the definition of 3-5B's “any declaration”;
5) In the current wording of the _LRM_, “an encapsulation” of {Reference, Reference_Holder, Container_Array} shall ••not•• be capable of “inhibit[ing] external access to implement properties of the definition” of public declaration of the Variable_Indexing aspect on the incomplete declaration of Container.
Therefore because of the “••not•• capable of” there, Steelman 3-5B is clearly not satisfied for Container's Variable_Indexing with respect to declarations of each of {Reference, Reference_Holder, Container_Array}.

Steelman 3-5B grants no exception for ‘chain migration’ of one declaration (e.g., public declaration of Variable_Indexing) having the tenacity to •pull• (or should I say, •pollute•) declarations forcibly from should-have-been private declaration-list into being •forced• public declarations.  Indeed, not only does Steelman 3-5B not grant such a chain-migration pulling of declarations from private to public (or should I say, polluting public view with should-have-been private declarations), Steelman 3-5B goes the extra mile in precluding any exceptions whatsoever, even overtly calling out this very situation of automatically generated operations 3 decades ahead of time as not being an exception to the requirement.

It seems that modern Ada's compliance with Steelman 3-5B needs to be downgraded from full to partial due to this topic (and perhaps any other yet-to-be-discovered aspects' chain-migrations of should-have-been private declarations to forced-public declarations).

Re: Visibility of Indexing aspects

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:aeeb29f7-86d1-4b18-9312-03e1239f22b0@googlegroups.com...
On Wednesday, July 25, 2018 at 7:12:24 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message
> news:3eebe2fb-f066-4248-9b2f-1db32497fd82@googlegroups.com...
...
>> ...
>> >The _LRM_'s forcing of {Reference, Reference_Holder, Container_Array, 
>> >...}
>> >to be public declarations ...
>>
>> ...is perfectly fine -- there's nothing wrong or dangerous with using 
>> them
>> directly. Indeed, "indexing" is just a shorthand for a longer call 
>> involving
>> Reference -- you're always allowed to make the longer call
>
>Yeah, unyieldingly demanding that unnecessary feature is the root-cause of 
>the
>violation of Steelman 3-5B detailed far below.

(1) No one reads any of your babble, simply because it is way too long for a 
"fun", non-required site. Say something consisely and stop! I struggle with 
this myself at times, but you're 10 times worse (which I didn't think was 
possible. :-)

(2) Steelman is only relevant (if it is relevant at all) for evaluating a 
new language design. Ada hasn't been a new design for decades --  
compatibility with existing code and existing Ada principles is what matters 
today. I cannot recall the last time that Steelman even came up in language 
discussions - there hasn't been a significant consideration of it in 
decades. (In part because it hasn't been updated in decades -- it predates 
OOP, for instance.)

(3) It's most important for a language to be self-consistent, rather than 
following some external model of purity. And it's definitely possible to 
hide too much.

(4) Ada doesn't really have user-defined indexing; it has some syntactic 
sugar that gives the illusion of user-defined indexing. The rules (static 
and dynamic) for it all stem from the underlying mechanism; it has rather 
little on its own.

Languages with true user-defined indexing existed before Ada; Ichbiah must 
have intentionally chosen not to include that feature. A language defined 
today around such a feature would be very different than Ada -- it probably 
wouldn't even have built-in array type. (An array is just another kind of 
container, and it's very inconsistent to have it be wildly different in 
definition than other containers.) Ada has so many bizarre rules around the 
use of built-ins that trying to reproduce it in a consistent way would lead 
to madness (dozens of special-case rules that exist only for compatibility). 
[Dmitry is right that it could be done, in the sense that anything can be 
done given enough money  and/or desire. But it wouldn't make any realistic 
sense to be done.]

I need to write that long-thought about blog entry outlining how I would 
change Ada given a blank slate. It would be something on the line of what 
Dmitry suggests, but almost all aspect-based (explicit interfaces are 
useless IMHO).

                                           Randy.

Re: Visibility of Indexing aspects

[Shark8]

On Wednesday, July 25, 2018 at 6:12:24 PM UTC-6, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:googlegroups.com...
> On Wednesday, July 25, 2018 at 2:58:44 PM UTC-5, AdaMagica wrote:
> >> Much ado about nothing.
> >>
> >> The writer of this code erroneously put things in the private part which
> >> should have been public. There is a compiler bug leaking from privacy
> >>which seduced the writer into thinking that his wrong code is correct.
> >>
> >> The RM is very precise about this, see the references in this thread.
> >>
> >> Love's Labours Lost with any further discussion.
> >
> >In other words, I made an insightful good point ...
> 
> Sounds like babble to me. What's used by the client has to be public, 
> period.

But this is legal:

Package K is
  Type Example is private;
Private
  Type Example is null record;
  For Example'Size use 4;
End K;

Package J is
  Type Hex is range 16#0#..16#F#
  with Size => 4;
   
  Type Ex_2 is record
    Item_1 : Hex;
    Item_2 : K.Example;
  end record
  with Size => 8;

End J;

> ...
> >The _LRM_'s forcing of {Reference, Reference_Holder, Container_Array, ...} 
> >to be public declarations ...
> 
> ...is perfectly fine -- there's nothing wrong or dangerous with using them 
> directly. Indeed, "indexing" is just a shorthand for a longer call involving 
> Reference -- you're always allowed to make the longer call, just like you 
> are allowed to put in .all even if you could have omitted it. We went to 
> substantial lengths to ensure that you can't keep a reference value longer 
> than the existence of the return object from Reference -- regardless of how 
> you use the package. (Telling people not to do something is never an 
> effective technique for safety!)

But that's not the issue that is being cited in the original post.
The issue is that all the indexing-attributes are declared/used in the private part and are [apparently] being used in the publicly visible part.

Is this correct?
Arguments could be made in either direction:
(for-allowing) This allows the public declaration to be kept clean of generally non-relevant details; much like declaring stream input/output functions needn't be made explicitly public to work (due to the stream attributes being accessable).
(for-disallowing) The indexable interface may not be intended for use outside of the PRIVATE visibility space (BODY, children's private, children's body).

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Thursday, July 26, 2018 at 3:31:04 PM UTC-5, Shark8 wrote:
> On Wednesday, July 25, 2018 at 6:12:24 PM UTC-6, Randy Brukardt wrote:
> > "Dan'l Miller" wrote in message 
> > news:googlegroups.com...
> > On Wednesday, July 25, 2018 at 2:58:44 PM UTC-5, AdaMagica wrote:
> > >> Much ado about nothing.
> > >>
> > >> The writer of this code erroneously put things in the private part which
> > >> should have been public. There is a compiler bug leaking from privacy
> > >>which seduced the writer into thinking that his wrong code is correct.
> > >>
> > >> The RM is very precise about this, see the references in this thread.
> > >>
> > >> Love's Labours Lost with any further discussion.
> > >
> > >In other words, I made an insightful good point ...
> > 
> > Sounds like babble to me. What's used by the client has to be public, 
> > period.
> 
> But this is legal:
> 
> Package K is
>   Type Example is private;
> Private
>   Type Example is null record;
>   For Example'Size use 4;
> End K;
> 
> Package J is
>   Type Hex is range 16#0#..16#F#
>   with Size => 4;
>    
>   Type Ex_2 is record
>     Item_1 : Hex;
>     Item_2 : K.Example;
>   end record
>   with Size => 8;
> 
> End J;
> 
> > ...
> > >The _LRM_'s forcing of {Reference, Reference_Holder, Container_Array, ...} 
> > >to be public declarations ...
> > 
> > ...is perfectly fine -- there's nothing wrong or dangerous with using them 
> > directly. Indeed, "indexing" is just a shorthand for a longer call involving 
> > Reference -- you're always allowed to make the longer call, just like you 
> > are allowed to put in .all even if you could have omitted it. We went to 
> > substantial lengths to ensure that you can't keep a reference value longer 
> > than the existence of the return object from Reference -- regardless of how 
> > you use the package. (Telling people not to do something is never an 
> > effective technique for safety!)
> 
> But that's not the issue that is being cited in the original post.
> The issue is that all the indexing-attributes are declared/used in the private part and are [apparently]
> being used in the publicly visible part.
> 
> Is this correct?

Yes that is correct regarding the OP, but my replies were requesting what the wonderful Ada vision for the alternative to this so-called “severe bug” are.  So far the only wonderful Ada vision for a better world than the “severe bug” is to chain-migrate •all• the intended-to-be-private declarations of •all• of {Variable_Indexing, Reference, Refence_Holder, Container_Array, …} gratuitously up to a polluted public view to satisfy the gratuitous over-achievement requirement of _AARM_:2016's ¶22/3 of §4.1.6 on page 189 so that the same semantics shall be able to written in 5 different ways (when the programmer overtly considered 4 of the 5 a bad idea), which is a worse vomit of intended-to-be-private declarations into public than what the so-called “severe bug” divulged:

Find (IB,"pear").Data.all := Element'(...); -- Traditional call
IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
IB.Find ("pear") := Element'(...); -- Implicit dereference (see 4.1.5)
IB ("pear") := Element'(...); -- Implicit indexing and dereference
IB ("pear").Data.all := Element'(...); -- Implicit indexing only

Apparently in subsequent replies the justifications for this gratuitous over-achievement requirement of mandating 5 different syntaxes of writing the same semantics (even when the programmer considers 4 of them as a bad idea) is:
1) (perceived?) effort reduction by compiler writers
and
2) syntactic-sugar features get a green-lighted free pass but software-engineering principles (e.g., Steelman requirement 3-5B) get prioritized lower, or worse, perhaps are viewed as governing Ada83-only in the dustbin of history.

Re: Visibility of Indexing aspects

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:f923e960-d3de-4f65-91c6-bbf0a898d2f8@googlegroups.com...
> On Wednesday, July 25, 2018 at 6:12:24 PM UTC-6, Randy Brukardt wrote:
...
>> Sounds like babble to me. What's used by the client has to be public,
>> period.
>
> But this is legal:
>
> Package K is
>  Type Example is private;
> Private
>  Type Example is null record;
>  For Example'Size use 4;
> End K;
>
> Package J is
>  Type Hex is range 16#0#..16#F#
>  with Size => 4;
>
>  Type Ex_2 is record
>    Item_1 : Hex;
>    Item_2 : K.Example;
>  end record
>  with Size => 8;
>
> End J;

Yes, and that's a significant bug in Ada. Ada excepts representational 
things from privacy rules, and that causes a variety of problems. I would 
argue that if you want to explictly use the size of something, then it needs 
to have been specified visibly.

But like seemingly everything, that's too incompatible to do now.

...
> But that's not the issue that is being cited in the original post.
Surely: but it was one of the issues that Dan'l was writing a novel about.

> The issue is that all the indexing-attributes are declared/used in the
> private part and are [apparently] being used in the publicly visible part.
>
> Is this correct?
> Arguments could be made in either direction:
> (for-allowing) This allows the public declaration to be kept clean of
> generally non-relevant details; much like declaring stream input/output
> functions needn't be made explicitly public to work (due to the stream
> attributes being accessable).

Surely, but the availability of the core operation is even more important. 
Stream attributes work much like overriding; the actual body called is 
determined by the definition in the private part, but there always is a body 
(whether something is defined in the private part or not).

More generally, that model works for any operation that is *visibly* 
available. Stream attributes, inherited subprograms, etc. It doesn't work 
for operations which are being defined for the first time and aren't 
available by default (iteration, indexing, hopefully literals, etc.)

One could imagine having an extra declaration that some indexing is going to 
be provided in the private part. That would be pretty messy (since the type 
of the index(s) would have to be provided along with existence of the 
operation) but it could be done. We just didn't see any reason to bother 
with doing it, since typically one wants to be able to use the long-hand 
form (that is, the explicit function calls) in some cases. (You might not 
want to actually retrieve the element, for instance.)

> (for-disallowing) The indexable interface may not be intended for use 
> outside of
>the PRIVATE visibility space (BODY, children's private, children's body).

Correct; you want to be able to have the ability to define such things only 
for private use.

                                    Randy.

Re: Visibility of Indexing aspects

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:71ab145a-83fd-46af-81c3-fe72c67c6897@googlegroups.com...
> ...(even when the programmer considers 4 of them as a bad idea) ...

A pretty inflexible programmer if you ask me. This is the same sort of 
programmer that then complains that the performance of indexing isn't good 
enough, because they are triggering all of this expensive mechanism rather 
than directly doing something simple.

I surely hope this programmer never works for me or tries to buy anything 
from me.

                                        Randy.

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Friday, July 27, 2018 at 5:06:00 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:71ab145a-83fd-46af-81c3-fe72c67c6897@googlegroups.com...
> > ...(even when the programmer considers 4 of them as a bad idea) ...
> 
> A pretty inflexible programmer if you ask me. This is the same sort of 
> programmer that then complains that the performance of indexing isn't good 
> enough, because they are triggering all of this expensive mechanism rather 
> than directly doing something simple.

Expensive?  Gee, I would think that precisely the same machine code verbatim would be generated for each of the following syntactic variants of the one and only same semantic meaning:

Find (IB,"pear").Data.all := Element'(...); -- Traditional call 
IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view 
IB.Find ("pear") := Element'(...); -- Implicit dereference (see 4.1.5) 
IB ("pear") := Element'(...); -- Implicit indexing and dereference 
IB ("pear").Data.all := Element'(...); -- Implicit indexing only 

> I surely hope this programmer never works for me or tries to buy anything 
> from me.

If you'd ever see my résumé, it is obvious that I prefer programmers who discover clever less-is-more designs that do vastly more via vast effort-reduction:

One time I worked at a company that shrank a room-sized telephone switch down to a single FPGA.  In so doing, we accidentally designed astronomical scale at super efficiency & speed:

1) the biggest best clickless wire-tap machine on the planet that can wire-tap 100% of the telephone calls passing through it, not the mere 1% as many of the competing telephone switches more-is-more designs do,

2) the telephone switch that has made those ten-thousand-attendee conference-calls possible that are so popular nowadays in the financial world for earning statements to the shareholders;
and

3) when a national emergency occurs, can ring all the hundreds-of-thousands of telephones throughout an entire metropolitan area •concurrently• to play a listen-only looped FEMA message-du-jour in the household's same native-tongue natural language as the natural language utilized to print their billing statement.

Re: Visibility of Indexing aspects

[Randy Brukardt]

(Sorry about breaking the thread, the reference headers have gotten too long 
for the news server to accept them. - RLB)

"Dan'l Miller" <optikos@verizon.net> wrote in message
news:ebf25374-fbd0-4239-9f24-1496b7699f74@googlegroups.com...
>On Friday, July 27, 2018 at 5:06:00 PM UTC-5, Randy Brukardt wrote:
>> "Dan'l Miller" wrote in message
>> news:71ab145a-83fd-46af-81c3-fe72c67c6897@googlegroups.com...
>> > ...(even when the programmer considers 4 of them as a bad idea) ...
>>
>> A pretty inflexible programmer if you ask me. This is the same sort of
>> programmer that then complains that the performance of indexing isn't
>> good
> enough, because they are triggering all of this expensive mechanism rather
>> than directly doing something simple.
>
>Expensive?  Gee, I would think that precisely the same machine code
>verbatim
>would be generated for each of the following syntactic variants of the one
>and
>only same semantic meaning:
>
>Find (IB,"pear").Data.all := Element'(...); -- Traditional call
>IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
>IB.Find ("pear") := Element'(...); -- Implicit dereference (see 4.1.5)
>IB ("pear") := Element'(...); -- Implicit indexing and dereference
>IB ("pear").Data.all := Element'(...); -- Implicit indexing only

Surely, and all 5 of these are quite expensive, because the use of Reference
(which is implicit in all 5 of these!) requires returning (and thus creating
and destroying) a controlled, composite object. [GNAT has a non-standard way
of eliminating the controlled part, which of course makes the use of the
containers substantially less safe.]

My point is that a programmer that truly cares about performance (and
hopefully that will only be concerning in a few critical situations) would
avoid using Reference at all if there isn't a need to update-in-place part
of the element. That is, one would still use the underlying operations, but
individually rather than all automatically as part of a set.

                          Randy.

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Thursday, August 2, 2018 at 3:31:18 PM UTC-5, Randy Brukardt wrote:
> (Sorry about breaking the thread, the reference headers have gotten too long 
> for the news server to accept them. - RLB)
> 
> "Dan'l Miller" wrote in message
> news:ebf25374-fbd0-4239-9f24-1496b7699f74@googlegroups.com...
> >On Friday, July 27, 2018 at 5:06:00 PM UTC-5, Randy Brukardt wrote:
> >> "Dan'l Miller" wrote in message
> >> news:71ab145a-83fd-46af-81c3-fe72c67c6897@googlegroups.com...
> >> > ...(even when the programmer considers 4 of them as a bad idea) ...
> >>
> >> A pretty inflexible programmer if you ask me. This is the same sort of
> >> programmer that then complains that the performance of indexing isn't
> >> good
> > enough, because they are triggering all of this expensive mechanism rather
> >> than directly doing something simple.
> >
> >Expensive?  Gee, I would think that precisely the same machine code
> >verbatim
> >would be generated for each of the following syntactic variants of the one
> >and
> >only same semantic meaning:
> >
> >Find (IB,"pear").Data.all := Element'(...); -- Traditional call
> >IB.Find ("pear").Data.all := Element'(...); -- Call of prefixed view
> >IB.Find ("pear") := Element'(...); -- Implicit dereference (see 4.1.5)
> >IB ("pear") := Element'(...); -- Implicit indexing and dereference
> >IB ("pear").Data.all := Element'(...); -- Implicit indexing only
> 
> Surely, and all 5 of these are quite expensive, because the use of Reference
> (which is implicit in all 5 of these!) requires returning (and thus creating
> and destroying) a controlled, composite object. [GNAT has a non-standard way
> of eliminating the controlled part, which of course makes the use of the
> containers substantially less safe.]
> 
> My point is that a programmer that truly cares about performance (and
> hopefully that will only be concerning in a few critical situations) would
> avoid using Reference at all if there isn't a need to update-in-place part
> of the element. That is, one would still use the underlying operations, but
> individually rather than all automatically as part of a set.
> 
>                           Randy.

In the above-mentioned case of prohibiting 4 of the 5, the programmer seeks not performance improvement.  The programmer seeks proscribing the retention of certain* data and structure by the outside-of-this-package world—topics which the outside-of-this-package world has no business retaining or using directly or abusing, syntactic sugar notwithstanding, and historical pre-syntactic-sugar idioms notwithstanding.  The Steelman 3-5B requirement is all about the app-domain designer overtly intentionally proscribing certain* semantics from ever being able to appear in the outside-of-package world.  Steelman 3-5B is not about some clever performance tweaking.

* The certain semantics to be proscribed outside of the declaring package is any form of letting private guts hang out publicly, as some sort of semantic hernia.  {Reference, Reference_Holder, Container_Array} in OP are all intended to be guts internal within the package's private view's abdominal muscle wall, not a semantic hernia gratuitously (mis)placed in the public view of the package.

Re: Visibility of Indexing aspects

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:dc0f1491-0e8c-43c5-a78f-e32d59df5f03@googlegroups.com...
On Thursday, August 2, 2018 at 3:31:18 PM UTC-5, Randy Brukardt wrote:
...
>> My point is that a programmer that truly cares about performance (and
>> hopefully that will only be concerning in a few critical situations) 
>> would
>> avoid using Reference at all if there isn't a need to update-in-place 
>> part
>> of the element. That is, one would still use the underlying operations, 
>> but
>> individually rather than all automatically as part of a set.

>In the above-mentioned case of prohibiting 4 of the 5, the programmer
>seeks not performance improvement.

Better programmers don't worry about performance all of the time, but 
*everyone* has to worry about it some of the time.

>The programmer seeks proscribing the retention of certain* data and
>structure by the outside-of-this-package world-topics which the
>outside-of-this-package world has no business retaining or using directly
>or abusing, ...

This is an utterly false statement; there is plenty of reasons to use the 
various parts directly; specifically for improved performance. Almost 
everything used in the indexing operations previously existed in the Ada 
2005 version of the container, after all.

So, since you're starting with a pair of fallicies, the rest of what you 
have to say is irrelevant. ("if False then anything" is a true [and useless] 
statement.)

                                            Randy.

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Friday, August 3, 2018 at 3:56:59 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" <optikos@verizon.net> wrote in message 
> news:dc0f1491-0e8c-43c5-a78f-e32d59df5f03@googlegroups.com...
> On Thursday, August 2, 2018 at 3:31:18 PM UTC-5, Randy Brukardt wrote:
> ...
> >> My point is that a programmer that truly cares about performance (and
> >> hopefully that will only be concerning in a few critical situations) 
> >> would
> >> avoid using Reference at all if there isn't a need to update-in-place 
> >> part
> >> of the element. That is, one would still use the underlying operations, 
> >> but
> >> individually rather than all automatically as part of a set.
> 
> >In the above-mentioned case of prohibiting 4 of the 5, the programmer
> >seeks not performance improvement.
> 
> Better programmers don't worry about performance all of the time, but 
> *everyone* has to worry about it some of the time.
> 
> >The programmer seeks proscribing the retention of certain* data and
> >structure by the outside-of-this-package world-topics which the
> >outside-of-this-package world has no business retaining or using directly
> >or abusing, ...
> 
> This is an utterly false statement; there is plenty of reasons to use the 
> various parts directly; specifically for improved performance. Almost 
> everything used in the indexing operations previously existed in the Ada 
> 2005 version of the container, after all.
> 
> So, since you're starting with a pair of fallicies, the rest of what you 
> have to say is irrelevant. ("if False then anything" is a true [and useless] 
> statement.)
> 
>                                             Randy.

Ummmmmmmmm, what is so incredibly “expensive” about Element => Self.Data(Index)'Access in OP?  You seem to be making some sort of gross inefficiency point, but the core piece of this conversation is OP's seminal-referent library •forcing• the usage of only Element => Self.Data(Index)'Access, which is in effect ‘give me the von Neumann address of an element in the array (as an alias)’.  I am a little confused how obtaining the von Neumann address of an element in an array causes gross inefficiency; it seems like such a straight-forward lightweight operation:  an integer calculated by mere garden-variety pointer arithmetic of base-address plus offset.

I am a little confused how even the “(as an alias)” part causes gross inefficiency in execution time expended.  It might complicate drastically the •release• of the array by not easily knowing when all of the elements have been de-aliased, but when to late-release the array is not a gross inefficiency of execution time expended; it is mere delay in time pessimistically until certainty has been reached that all the aliases' lifetimes have ended.  But even that meticulous lifetime tracking seems trivial:  reference count the number of aliases-to-elements anywhere in the array; don't dealloc the entire array until the alias-lifetime reference count returns to zero.

Re: Visibility of Indexing aspects

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:cc25c794-5986-4f6e-9d5e-0ec20a4f47d0@googlegroups.com...
...
>Ummmmmmmmm, what is so incredibly "expensive" about Element => 
>Self.Data(Index)'Access in OP?

Nothing is expensive about *that*, but it's also very unsafe by itself (this 
either prevents a container from ever reusuing memory, or essentially 
requires being OK with dangling pointers and the erroneousness that they 
cause).

Our requirement was that the user-defined dereference mechanism needs to be 
safe (at least possible to be safe), and that requires the container to be 
able to find out when the dereference ceases to exist. At that point, the 
container can free the underlying memory if need be. (For an extreme 
example, consider a persistent container, where the object only should exist 
in memory so long as it is being used there.) The design that we came up 
with for Ada 2012 uses finalization for this notification; we looked at 
other mechanisms, but they would have had similar overhead.

The Ada containers use the finalization to clear the tampering check (which 
prevents deleting of elements while the dereference exists); other uses are 
possible, of course.

Without these sorts of checks, Ada containers would be no more safe than C 
code. In particular, Ada programmers do not expect checked indexing to be 
unsafe, so syntax of C(I) being unsafe would be a particular surprise.

                                    Randy.

Re: Visibility of Indexing aspects

[Dmitry A. Kazakov]

On 2018-08-06 23:46, Randy Brukardt wrote:
> "Dan'l Miller" <optikos@verizon.net> wrote in message
> news:cc25c794-5986-4f6e-9d5e-0ec20a4f47d0@googlegroups.com...
> ...
>> Ummmmmmmmm, what is so incredibly "expensive" about Element =>
>> Self.Data(Index)'Access in OP?
> 
> Nothing is expensive about *that*, but it's also very unsafe by itself (this
> either prevents a container from ever reusuing memory, or essentially
> requires being OK with dangling pointers and the erroneousness that they
> cause).
> 
> Our requirement was that the user-defined dereference mechanism needs to be
> safe (at least possible to be safe), and that requires the container to be
> able to find out when the dereference ceases to exist. At that point, the
> container can free the underlying memory if need be. (For an extreme
> example, consider a persistent container, where the object only should exist
> in memory so long as it is being used there.) The design that we came up
> with for Ada 2012 uses finalization for this notification; we looked at
> other mechanisms, but they would have had similar overhead.
> 
> The Ada containers use the finalization to clear the tampering check (which
> prevents deleting of elements while the dereference exists); other uses are
> possible, of course.
> 
> Without these sorts of checks, Ada containers would be no more safe than C
> code. In particular, Ada programmers do not expect checked indexing to be
> unsafe, so syntax of C(I) being unsafe would be a particular surprise.

Right, exposing references, e.g. having named types of and explicit 
objects of, is always either unsafe or both unsafe and inefficient. 
There is no satisfactory solution on that path.

No way to decompose A(I):=X literally. After fixing Ada type system we 
should better try Update(A,I,X).

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

Re: Visibility of Indexing aspects

[Dan'l Miller]

On Monday, August 6, 2018 at 4:46:16 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:cc25c794-5986-4f6e-9d5e-0ec20a4f47d0@googlegroups.com...
> ...
> >Ummmmmmmmm, what is so incredibly "expensive" about Element => 
> >Self.Data(Index)'Access in OP?
> 
> Nothing is expensive about *that*, but it's also very unsafe by itself (this 
> either prevents a container from ever reusuing memory, or essentially 
> requires being OK with dangling pointers and the erroneousness that they 
> cause).
> 
> Our requirement was that the user-defined dereference mechanism needs to be 
> safe (at least possible to be safe), and that requires the container to be 
> able to find out when the dereference ceases to exist. At that point, the 
> container can free the underlying memory if need be. (For an extreme 
> example, consider a persistent container, where the object only should exist 
> in memory so long as it is being used there.) The design that we came up 
> with for Ada 2012 uses finalization for this notification; we looked at 
> other mechanisms, but they would have had similar overhead.
> 
> The Ada containers use the finalization to clear the tampering check (which 
> prevents deleting of elements while the dereference exists); other uses are 
> possible, of course.
> 
> Without these sorts of checks, Ada containers would be no more safe than C 
> code. In particular, Ada programmers do not expect checked indexing to be 
> unsafe, so syntax of C(I) being unsafe would be a particular surprise.
> 
>                                     Randy.

My reference-counting of aliases in my reply above concurs with what you saying in this reply of yours.

Randy, you make a strong argument for the compiler/language tracking the lifetime of aliases instead of leaving it as a library and/or app-domain responsibility.

Re: Visibility of Indexing aspects

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:62cefa64-4855-4d51-9216-519f260349d4@googlegroups.com...
...
> Randy, you make a strong argument for the compiler/language tracking the
> lifetime of aliases instead of leaving it as a library and/or app-domain 
> responsibility.

Programming language research seems to be moving toward compile-time rules 
preventing the need for lifetime tracking. One things we've considered (not 
seriously this go-around) is compile-time locking (essentially compile-time 
tampering checks, to use the Ada 2012 container terminology). Then there is 
no runtime overhead and no time-bomb from occassionally failing runtime 
checks. It mostly can be defined in terms of the Global aspect (as defined 
in Ada 2020), although it would be a rather big stick (lots of legit. stuff 
would also be prevented).

                                               Randy.