Access parameters and accessibility

Access parameters and accessibility

[Michael B.]

I'm reading the book "Programming in Ada 2005" of John Barnes and I have 
difficulties to understand the chapter about access parameters.
In chapter 10.7 on pages 197/198 he writes:

---
An access parameter can be passed on to another access parameter; 
typically the accessibility indication is passed on unchanged but in the 
unusual circumstance where the called subprogram is internal to the 
calling subprogram, the accessibility level is replaced by that of the 
(statically known) formal calling parameter if less than the original 
actual parameter.
---

Could someone give an example/explanation where this rule is used?
I tried to read the RM. Chapter 3.10.2 seems to be the right one but I 
don't understand it either...

Thanks in advance,

Michael

Re: Access parameters and accessibility

[Dmitry A. Kazakov]

On Mon, 15 Dec 2014 17:52:46 +0100, Michael B. wrote:

> I'm reading the book "Programming in Ada 2005" of John Barnes and I have 
> difficulties to understand the chapter about access parameters.
> In chapter 10.7 on pages 197/198 he writes:
> 
> ---
> An access parameter can be passed on to another access parameter; 
> typically the accessibility indication is passed on unchanged but in the 
> unusual circumstance where the called subprogram is internal to the 
> calling subprogram, the accessibility level is replaced by that of the 
> (statically known) formal calling parameter if less than the original 
> actual parameter.
> ---
> 
> Could someone give an example/explanation where this rule is used?

The rule is: don't ever use this.

Accessibility information is a booby trap placed to blow up your program
later, when you expect it least.

If you know what you are doing, you should when you pass a pointer around,
kill the accessibility information where possible, e.g. by converting to a
named access type, by using X.all'Unchecked_Access etc.

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

Re: Access parameters and accessibility

[Jeffrey Carter]

On 12/15/2014 10:54 AM, Dmitry A. Kazakov wrote:
> 
> The rule is: don't ever use this.

I second this.

Anonymous access types, of which access parameters are instances, are a bad
idea. The language would be better off without them.

Public access types, and public subprograms with parameters of access types, are
also bad ideas.

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36

Re: Access parameters and accessibility

[Michael B.]

I don't want to use this stuff for my own code. My problem is that I 
want to understand object orientation in Ada. And this seems to be 
impossible without a complete understanding of access types in all flavors.

The OO chapters in Barnes' book assume that you have a deep 
understanding of access types. I don't. And therefore I'm stuck.

So would you please help me to understand this paragraph?

Regards

Michael


On 12/15/14 19:48, Jeffrey Carter wrote:
> On 12/15/2014 10:54 AM, Dmitry A. Kazakov wrote:
>>
>> The rule is: don't ever use this.
>
> I second this.
>
> Anonymous access types, of which access parameters are instances, are a bad
> idea. The language would be better off without them.
>
> Public access types, and public subprograms with parameters of access types, are
> also bad ideas.
>

Re: Access parameters and accessibility

[Dmitry A. Kazakov]

On Mon, 15 Dec 2014 21:23:02 +0100, Michael B. wrote:

> I don't want to use this stuff for my own code. My problem is that I 
> want to understand object orientation in Ada. And this seems to be 
> impossible without a complete understanding of access types in all flavors.

You don't need access types to understand Ada's OO. Furthermore
accessibility checks and information has nothing to do with OO.

> So would you please help me to understand this paragraph?

It says that some information is hanged on the pointer's value implicitly.
The information contains a description of the context where the pointer was
obtained.

By this it violates manifest typing principle. It also does nominal typing.
Both are Ada's type system keystones.

The accessibility information is used on some other context where the
pointer is dereferenced or copied, in order to generate an exception
depending on the relation of this context to the origin context.

The rationale for this is that the pointer *might* become dangled, which in
most practical cases just wrong. The problem with the idea that the
decision is taken according to the pointer contexts, not the context of the
object itself (which would be impossible). So, basically, it is just an
arbitrary exception generator.

Since the thing sometimes generates exception and sometimes does not, it
also violates important OO principles, such as substitutability. Because it
makes the behavior context-dependent.

In short, it is a mess, the only thing you need to know about is how to
avoid it in your program.

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

Re: Access parameters and accessibility

[sbelmont700]

> 
> Could someone give an example/explanation where this rule is used?
> I tried to read the RM. Chapter 3.10.2 seems to be the right one but I 
> don't understand it either...
> 

As others have pointed out, anonymous access types are 'expert friendly' at best, and there is a whole host of history and compromises as to why they are how they are, most of which are obsolete in 2012.  For 99% of situations, you don't have to lose any sleep over any of this (though I disagree with the 'never ever ever' attitude of others).

However, long story short, using an 'access parameter' (i.e. an anonymous access type as a subprogram parameter) requires passing along some meta-data about the object for various esoteric situations when a runtime check might be required.  However, as the author points out, there are some (even rarer) cases where what would normally require a runtime check would be statically known to be ok, and thus could be performed without risk.  That's all it's saying.

This is compiler detail, not a language rule, so I would doubt you would find it in the LRM (perhaps in the AARM, as a note?)  If you are a masochist, the same author produced a whitepaper back in the day going into much more gory detail about all this (ACM Ada Letters, Jan/Feb 1995, page 45 specifically).

-sb

Re: Access parameters and accessibility

[Randy Brukardt]

"Michael B." <michaelb@example.com> wrote in message 
news:m6n3kr$t51$1@speranza.aioe.org...
> I'm reading the book "Programming in Ada 2005" of John Barnes and I have 
> difficulties to understand the chapter about access parameters.
> In chapter 10.7 on pages 197/198 he writes:
>
> ---
> An access parameter can be passed on to another access parameter; 
> typically the accessibility indication is passed on unchanged but in the 
> unusual circumstance where the called subprogram is internal to the 
> calling subprogram, the accessibility level is replaced by that of the 
> (statically known) formal calling parameter if less than the original 
> actual parameter.
> ---
>
> Could someone give an example/explanation where this rule is used?
> I tried to read the RM. Chapter 3.10.2 seems to be the right one but I 
> don't understand it either...

We in the ARG call discussing accessibility a "trip to the Heart of 
Darkness", and indeed, 3.10.2 is now informally called the "Heart of 
Darkness". I even put that into an AARM note (3.10.2(3.b/3)). Only the 
desperate or foolhardy venture there.

I had heaard about the issue that John mentions in this paragraph, but I 
never understood it (I don't think Janus/Ada does it). I've had it explained 
to me a couple of times, and I sort of understand it, but you'd have to pay 
me to spend an hour finding an example and writing up an appropriate 
explanation. It's that draining - I wouldn't do it for free. Sorry.

Besides, I agree with the others that it has nothing to do with OOP. Claw 
only uses anonymous access parameters to get the effect of in out parameters 
in functions (which isn't a problem with Ada 2012 anyway), and as Dmitry 
noted, it doesn't work very well. Anonymous access parameters: just say no!!

Finally, the model that John is talking about isn't sufficient to implement 
dynamic accessibility checks in Ada 2005 or Ada 2012. He's really talking 
about an implementation short-cut that should be irrelevant to understanding 
the feature anyway. (That is, it doesn't even belong in his book.) And that 
short-cut doesn't work. Indeed, no Ada compiler has ever actually 
implemented correct accessibility checking for Ada 2005 or later. We believe 
it is possible (Steve Baird and I have worked out correct implementation 
models, but no one has tried either yet). We're supposed to be writing an 
Ada-Europe paper -- but of course that requires a trip to the Heart of 
Darkness, and neither of us has been in much a hurry to take that trip!

The only thing to worry about vis-a-vis dynamic accessibility checking is 
that the object has to have a lifetime the same or longer than the access 
type. How that's implemented should not matter (unless of course you are 
trying to fix a compiler bug -- something most people here aren't going to 
do).

                                             Randy.

Re: Access parameters and accessibility

[Stefan.Lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 644 bytes --]

On Tue, 16 Dec 2014, Randy Brukardt wrote:

> Indeed, no Ada compiler has ever actually implemented correct 
> accessibility checking for Ada 2005 or later.

Could you envision the ARG to drop anonymous access parameters, or at 
least severely restrict their usage, in the next language revision?

If a language feature has not yet been properly implemented, you don't 
break working code by dropping this feature.

------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

Re: Access parameters and accessibility

[Natasha Kerensikova]

On 2014-12-16, Randy Brukardt <randy@rrsoftware.com> wrote:
> Anonymous access parameters: just say no!!

I still believe a case could be made for anonymous access to subprogram
parameters.

Generics and interfaces could of course be used instead of them, but I
feel they are often more cumbersome to use.


Natasha

Re: Access parameters and accessibility

[Dmitry A. Kazakov]

On Tue, 16 Dec 2014 09:08:40 +0000 (UTC), Natasha Kerensikova wrote:

> On 2014-12-16, Randy Brukardt <randy@rrsoftware.com> wrote:
>> Anonymous access parameters: just say no!!
> 
> I still believe a case could be made for anonymous access to subprogram
> parameters.

There should never have been such thing. Subprograms should have been an
in-parameter (90% of cases) or else a named access type (10% of cases).

Others already said that anonymous access was an workaround. There is the
list of issues it deals with:

1. lack of in-out parameters of functions
2. missing downward closures (subprograms as in-parameters)
3. unwillingness to implement full multiple inheritance (so mix-ins)
4. broken object construction (so the Rosen's trick to re-dispatch and also
for #2)
5. non-tagged task and PO types (so, aggregation + an access to the
container as a discriminant)

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

Re: Access parameters and accessibility

[Michael B.]

On 12/16/14 02:10, sbelmont700@gmail.com wrote:
> If you are a masochist, the same author produced a whitepaper back in
> the day going into much more gory detail about all this (ACM Ada
> Letters, Jan/Feb 1995, page 45 specifically).

Until yesterday I thought that I'm no masochist, but when I read the 
answers of other people to my question I'm not sure anymore ;-).

I tried to find the paper you mentioned. But the only source I found is 
the ACM website where I can buy it. Is this text somewhere publicly 
available?

Regards,

Michael

Re: Access parameters and accessibility

[Georg Bauhaus]

On 16.12.14 14:57, Michael B. wrote:
> On 12/16/14 02:10, sbelmont700@gmail.com wrote:
>> If you are a masochist, the same author produced a whitepaper back in
>> the day going into much more gory detail about all this (ACM Ada
>> Letters, Jan/Feb 1995, page 45 specifically).
>
> Until yesterday I thought that I'm no masochist, but when I read the answers of other people to my question I'm not sure anymore ;-).
>
> I tried to find the paper you mentioned. But the only source I found is the ACM website where I can buy it. Is this text somewhere publicly available?

The ACM library site states that a SIGAda membership
and a (free) ACM web account provide for free access.
I can't tell whether the "and" is semantically an "or",
but if you have both, they will do as promised.

I reckon the next university library has it, too, if not on
paper then as a scanned article, delivered as copy or electronically.

Re: Access parameters and accessibility

[Robert A Duff]

Natasha Kerensikova <lithiumcat@instinctive.eu> writes:

> On 2014-12-16, Randy Brukardt <randy@rrsoftware.com> wrote:
>> Anonymous access parameters: just say no!!
>
> I still believe a case could be made for anonymous access to subprogram
> parameters.

Yes, that's a completely different feature, and won't get you in any
trouble.  But those are conceptually subprograms, not pointers; the
syntax should be:

    procedure P(X: procedure ...

instead of the noisy:

    procedure P(X: not null access procedure ...

> Generics and interfaces could of course be used instead of them, but I
> feel they are often more cumbersome to use.

Yes.

Now what we need is lambdas.

- Bob

Re: Access parameters and accessibility

[Michael B.]

On 12/16/14 08:45, Randy Brukardt wrote:
> We in the ARG call discussing accessibility a "trip to the Heart of
> Darkness", and indeed, 3.10.2 is now informally called the "Heart of
> Darkness". I even put that into an AARM note (3.10.2(3.b/3)). Only the
> desperate or foolhardy venture there.

Heart of Darkness?! When reading this part of the ARM it felt a little 
bit weird. But I had no idea it could be *that* bad ;-).

> I had heaard about the issue that John mentions in this paragraph, but I
> never understood it (I don't think Janus/Ada does it). I've had it explained
> to me a couple of times, and I sort of understand it, but you'd have to pay
> me to spend an hour finding an example and writing up an appropriate
> explanation. It's that draining - I wouldn't do it for free. Sorry.

Does that mean I should give up on that issue as I will never be able to 
understand it?

> Besides, I agree with the others that it has nothing to do with OOP. Claw
> only uses anonymous access parameters to get the effect of in out parameters
> in functions (which isn't a problem with Ada 2012 anyway), and as Dmitry
> noted, it doesn't work very well. Anonymous access parameters: just say no!!

How can I avoid them when they are heavily used in so many libraries?
E.g. GtkAda: I just looked into some arbitrary .ads files from Gnat GPL 
2014 (glib-string.ads, glib-object.ads and gdk-event.ads) and found 
examples of the usage of anonymous access parameters.
You could argue that this is bad design, but rewriting all this code is 
not really an option for me.
And compared to writing GUIs in plain C it seems to be the lesser of two 
evils.

> Finally, the model that John is talking about isn't sufficient to implement
> dynamic accessibility checks in Ada 2005 or Ada 2012. He's really talking
> about an implementation short-cut that should be irrelevant to understanding
> the feature anyway. (That is, it doesn't even belong in his book.) And that
> short-cut doesn't work. Indeed, no Ada compiler has ever actually
> implemented correct accessibility checking for Ada 2005 or later. We believe
> it is possible (Steve Baird and I have worked out correct implementation
> models, but no one has tried either yet). We're supposed to be writing an
> Ada-Europe paper -- but of course that requires a trip to the Heart of
> Darkness, and neither of us has been in much a hurry to take that trip!

I'm looking forward to read this paper!

> The only thing to worry about vis-a-vis dynamic accessibility checking is
> that the object has to have a lifetime the same or longer than the access
> type.

At least this rule is easy to understand :-).

Regards,

Michael

Re: Access parameters and accessibility

[Randy Brukardt]

<Stefan.Lucks@uni-weimar.de> wrote in message 
news:alpine.DEB.2.11.1412160940270.7909@debian...
On Tue, 16 Dec 2014, Randy Brukardt wrote:

>> Indeed, no Ada compiler has ever actually implemented correct
>> accessibility checking for Ada 2005 or later.
>
>Could you envision the ARG to drop anonymous access parameters, or at
>least severely restrict their usage, in the next language revision?
>
>If a language feature has not yet been properly implemented, you don't
>break working code by dropping this feature.

No, because what's broken isn't really relevant to the proper use of the 
feature. Typically, it just means that Program_Error isn't raised in some 
cases in which it should be -- but those cases aren't very likely to occur 
in practice anyway.

What we've actually talked about is giving up on these checks and just 
letting misuse be erroneous. Most people don't want to go there if we don't 
have to, but since we already go there for Unchecked_Deallocation, we're 
already there. Proper dangling pointer checks would be too expensive, sadly 
(especially for non-allocated objects).

And of course the compatibility cost would be significant. We might consider 
some additional restrictions (on the line of "No_Coextensions" and 
"No_Anonymous_Allocators", see H.4), but I think that is as far as we could 
go.

                                     Randy.

Re: Access parameters and accessibility

[Randy Brukardt]

"Michael B." <michaelb@example.com> wrote in message 
news:m6q27d$l4s$1@speranza.aioe.org...
> On 12/16/14 08:45, Randy Brukardt wrote:
>> We in the ARG call discussing accessibility a "trip to the Heart of
>> Darkness", and indeed, 3.10.2 is now informally called the "Heart of
>> Darkness". I even put that into an AARM note (3.10.2(3.b/3)). Only the
>> desperate or foolhardy venture there.
>
> Heart of Darkness?! When reading this part of the ARM it felt a little bit 
> weird. But I had no idea it could be *that* bad ;-).
>
>> I had heaard about the issue that John mentions in this paragraph, but I
>> never understood it (I don't think Janus/Ada does it). I've had it 
>> explained
>> to me a couple of times, and I sort of understand it, but you'd have to 
>> pay
>> me to spend an hour finding an example and writing up an appropriate
>> explanation. It's that draining - I wouldn't do it for free. Sorry.
>
> Does that mean I should give up on that issue as I will never be able to 
> understand it?

Well, if you do understand it, we need you on the ARG. :-)

>> Besides, I agree with the others that it has nothing to do with OOP. Claw
>> only uses anonymous access parameters to get the effect of in out 
>> parameters
>> in functions (which isn't a problem with Ada 2012 anyway), and as Dmitry
>> noted, it doesn't work very well. Anonymous access parameters: just say 
>> no!!
>
> How can I avoid them when they are heavily used in so many libraries?

Get better-designed libraries.

> E.g. GtkAda: I just looked into some arbitrary .ads files from Gnat GPL 
> 2014 (glib-string.ads, glib-object.ads and gdk-event.ads) and found 
> examples of the usage of anonymous access parameters.
> You could argue that this is bad design, but rewriting all this code is 
> not really an option for me.
> And compared to writing GUIs in plain C it seems to be the lesser of two 
> evils.

You could write GUIs using Claw (see www.rrsoftware.com), which surely does 
not have this mess. (Of course, I'm biased about Claw.) No bare C required. 
That's true of many other libraries as well. One thing about GUI and 
containers libraries -- much like the weather, if you don't like one, there 
are plenty of others to use.

Anonymous access parameters tends to make calls ugly (because they have to 
be filled with 'Unchecked_Access), clutter the object declarations (because 
of the need to explicitly declare them aliased), and also have what Bob Duff 
calls a "tripping hazard" -- the fact that Program_Error might be raised if 
they are passed a local object. But that depends on how they are used in the 
implementation, so no users can know whether or not it is safe to pass a 
local.

...
>> The only thing to worry about vis-a-vis dynamic accessibility checking is
>> that the object has to have a lifetime the same or longer than the access
>> type.
>
> At least this rule is easy to understand :-).

Right. It's not 100% accurate, but trust me, you don't want to figure out 
the rules to perfect accuracy. Moreover, if you don't use anonymous access 
parameters and discriminants, and don't use 'Access in generic bodies, all 
of the checking will be done at compile-time, so you can just use the old 
"if it compiles, it must be right" strategy. Which is the best way to deal 
with accessibility -- unless of course you are trying to implement it.

                            Randy.

Re: Access parameters and accessibility

[Georg Bauhaus]

On 16.12.14 21:47, Randy Brukardt wrote:
> What we've actually talked about is giving up on these checks and just
> letting misuse be erroneous. Most people don't want to go there if we don't
> have to, but since we already go there for Unchecked_Deallocation, we're
> already there. Proper dangling pointer checks would be too expensive, sadly
> (especially for non-allocated objects).

I imagine seeing future subprogram specs look like

   procedure I_Know_what_I_am_doing
      (Param : not null unchecked_access Typ);


ARGh ;-)

Re: Access parameters and accessibility

[sbelmont700]

On Tuesday, December 16, 2014 8:57:50 AM UTC-5, Michael B. wrote:
> 
> I tried to find the paper you mentioned. But the only source I found is 
> the ACM website where I can buy it. Is this text somewhere publicly 
> available?
> 


I have a copy of the paper around, if you are that into things, but it's certainly not a casual read, nor does it really appeal to anyone except for the phony-tough or crazy-brave.  In any case, to go into a little more detail, the whole model is based on the idea of comparing the relative 'depths' (i.e. source code nesting), but that's a messy proposition because the depth is dynamic.  The relative example is as follows:

procedure Example6  is
   
   type T is ...;
   
   procedure P1(XP1 : access T) is
      type A is access T;
      Ptr: A := null;
      
      procedure P2(XP2: access T) is
      begin
         Ptr := A(XP2);
      end P2;
      
   begin
      P2(XP1);
   end P1;
   
   X : aliased T;

begin
   declare
      Y : aliased T:
    begin
      declare
         Z : aliased T;
       begin
         P1(X'Access);  
         P1(Y'Access);
         P1(Z'Access);   -- pass or fail?
       end;
    end;
end Example6;

In this example, note that all the objects X, Y and Z are all longer lived than type A, which conceptually only exists for the duration that P1 is executing, so each conversion should pass.  But also note that the "depths" of the objects that P1 (and consequently, P2) is getting are becoming progressively "deeper" as each declarative block gets elaborated.  The question then becomes what "depths" should the conversion in P2 be checking?  If the normal block-nesting level was used (where X is 1, Y is 2, and Z is 3), then Z would become evaluated as "too deep", since A would be 2 and Z would be 3, and you would get an erroneous program error doing the conversion.

So you can tweak things to say that in these special cases, you pass the *lower* of either the actual object depth or P1 itself.  So, in this case, now Z will pass the dynamic check since instead of getting the depth of Z, P2 gets the depth of P1 (since 1<3).  Now you can nest the declarative blocks a billion levels deep, and the proposed model still adheres to the LRM.

Again, it's important to stress that this is just one special case of one special part of just one possible implementation of one special-case language feature from twenty years ago, and that none of this should weigh heavily on your mind when learning or using Ada.  

-sb

Re: Access parameters and accessibility

[Adam Beneschan]

On Tuesday, December 16, 2014 11:46:59 AM UTC-8, Michael B. wrote:

> > Besides, I agree with the others that it has nothing to do with OOP. Claw
> > only uses anonymous access parameters to get the effect of in out parameters
> > in functions (which isn't a problem with Ada 2012 anyway), and as Dmitry
> > noted, it doesn't work very well. Anonymous access parameters: just say no!!
> 
> How can I avoid them when they are heavily used in so many libraries?
> E.g. GtkAda: I just looked into some arbitrary .ads files from Gnat GPL 
> 2014 (glib-string.ads, glib-object.ads and gdk-event.ads) and found 
> examples of the usage of anonymous access parameters.
> You could argue that this is bad design, but rewriting all this code is 
> not really an option for me.
> And compared to writing GUIs in plain C it seems to be the lesser of two 
> evils.

I don't see how it could be a problem if you *use* a subprogram that requires an anonymous access parameter.  You can pretty much just pass in an object of any matching named access type, or 'Access (or 'Unchecked_Access) of a matching object.  You don't need to create any new anonymous access types in order to do so.

I'm sure Randy was being tongue-in-cheek when he said "get better libraries".  For one thing, you'd have to get better libraries than the libraries Ada provides, because Ada defines some subprograms with anonymous access parameters--namely Ada.Tags.Generic_Dispatching_Constructor, Ada.Execution_Time.Timers.Timer, and Read|Write_Exception_Occurrence in Ada.Exceptions.  Also, the stream attribute subprograms ('Read, 'Write, etc.) all have anonymous access parameters, and you have to *write* a subprogram that has an anonymous access parameter in order to use it as the stream subprogram for a type.  Quelle horreur!  Anyway, I think you can avoid defining new subprograms that take anonymous access parameters (except where needed for streams, or for Generic_Dispatching_Constructor) and not add to the problem, but I don't see any value in avoiding existing libraries.

                                -- Adam

Re: Access parameters and accessibility

[Natasha Kerensikova]

On 2014-12-16, Randy Brukardt <randy@rrsoftware.com> wrote:
> Right. It's not 100% accurate, but trust me, you don't want to figure out 
> the rules to perfect accuracy. Moreover, if you don't use anonymous access 
> parameters and discriminants, and don't use 'Access in generic bodies, all 
> of the checking will be done at compile-time, so you can just use the old 
> "if it compiles, it must be right" strategy. Which is the best way to deal 
> with accessibility -- unless of course you are trying to implement it.

Now you got me really worried, because I thouhgt access discriminants
were safe. It was under that assumption that I actually started to
really like them.

More specifically, the pattern I caught myself using a lot looks like
the following:

   type Preprocessed_Data (Input_Data : access Input_Data_Type) is record
      Computed_Value_1 : Type_1;
      Computed_Value_2 : Type_2;
   end record;

   procedure Private_Helper (Data : in Preprocessed_Data) is
   begin
      --  Do stuff qui Computed_Value_* and maybe also with Input_Data
   end Private_Helper;

   procedure Process (Input_Data : in out Input_Data_Type) is
      Data : Preprocessed_Data (Input_Data'Access);
   begin
      --  Initialize Data.Computed_Value_*
      Private_Helper (Data);
   end Process;

For course, it means that Input_Data is actually aliased, so it must be
of a tagged type (or maybe a limited type works too?).

That way a strong connection is maintained between the original data and
whatever is derived from it, and it gets to be handled in a single value
rather than letting the number of arguments explode when there are
several preprocessed types or steps. Though I started building such
types to use generics that expected a single type/value.

Am I doing something danegerous here?
Should I try to find another pattern to achieve the same effects?

From what I understood, here accessibility is statically known to be
fine, isn't it? Or is there a trap hidden in there?


Thanks for your thoughts,
Natasha

Re: Access parameters and accessibility

[Dmitry A. Kazakov]

On Wed, 17 Dec 2014 07:02:56 +0000 (UTC), Natasha Kerensikova wrote:

> Now you got me really worried, because I thouhgt access discriminants
> were safe. It was under that assumption that I actually started to
> really like them.
> 
> More specifically, the pattern I caught myself using a lot looks like
> the following:
> 
>    type Preprocessed_Data (Input_Data : access Input_Data_Type) is record

not null access?

>       Computed_Value_1 : Type_1;
>       Computed_Value_2 : Type_2;
>    end record;
> 
>    procedure Private_Helper (Data : in Preprocessed_Data) is
>    begin
>       --  Do stuff qui Computed_Value_* and maybe also with Input_Data
>    end Private_Helper;
> 
>    procedure Process (Input_Data : in out Input_Data_Type) is
>       Data : Preprocessed_Data (Input_Data'Access);
>    begin
>       --  Initialize Data.Computed_Value_*
>       Private_Helper (Data);
>    end Process;
> 
> For course, it means that Input_Data is actually aliased, so it must be
> of a tagged type (or maybe a limited type works too?).
> 
> That way a strong connection is maintained between the original data and
> whatever is derived from it, and it gets to be handled in a single value
> rather than letting the number of arguments explode when there are
> several preprocessed types or steps. Though I started building such
> types to use generics that expected a single type/value.
> 
> Am I doing something danegerous here?
> Should I try to find another pattern to achieve the same effects?

The language should. Access disciminant is a hack. The pattern should have
been:

   procedure Process (Input_Data : in out Input_Data_Type) is
      Data : Preprocessed_Data (Input_Data);

with a proper constructor "virtualizing" Input_Data_Type "discriminant" of
Preprocessed_Data.

   type Preprocessed_Data (Input_Data : Input_Data_Type) is ...;
private
   type Preprocessed_Data is ... -- No discriminant actually
   overriding
      procedure Initialize (Input_Data : Input_Data_Type);

> From what I understood, here accessibility is statically known to be
> fine, isn't it? Or is there a trap hidden in there?

AFAIK, it is safe.

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

Re: Access parameters and accessibility

[Natasha Kerensikova]

On 2014-12-17, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 17 Dec 2014 07:02:56 +0000 (UTC), Natasha Kerensikova wrote:
>
>> Now you got me really worried, because I thouhgt access discriminants
>> were safe. It was under that assumption that I actually started to
>> really like them.
>> 
>> More specifically, the pattern I caught myself using a lot looks like
>> the following:
>> 
>>    type Preprocessed_Data (Input_Data : access Input_Data_Type) is record
>
> not null access?

I tought access discriminants were not allowed to be null.
Has that changed?
Or do you advise "not null access" to make it explicit?


Natasha

Re: Access parameters and accessibility

[Michael B.]

On 12/16/14 22:34, sbelmont700@gmail.com wrote:
> I have a copy of the paper around, if you are that into things, but
> it's certainly not a casual read, nor does it really appeal to anyone
> except for the phony-tough or crazy-brave.


I would be happy if you could send me a copy. My mail address is:

mb_public <at> safe-mail <dot> net

I hope it will not cause too much damage to my mental health ;-)


> procedure Example6  is
>
>     type T is ...;
>
>     procedure P1(XP1 : access T) is
>        type A is access T;
>        Ptr: A := null;
>
>        procedure P2(XP2: access T) is
>        begin
>           Ptr := A(XP2);
>        end P2;
>
>     begin
>        P2(XP1);
>     end P1;
>
>     X : aliased T;
>
> begin
>     declare
>        Y : aliased T:
>      begin
>        declare
>           Z : aliased T;
>         begin
>           P1(X'Access);
>           P1(Y'Access);
>           P1(Z'Access);   -- pass or fail?
>         end;
>      end;
> end Example6;


> In this example, note that all the objects X, Y and Z are all longer
> lived than type A, which conceptually only exists for the duration
> that P1 is executing, so each conversion should pass.  But also note
> that the "depths" of the objects that P1 (and consequently, P2) is
> getting are becoming progressively "deeper" as each declarative block
> gets elaborated.  The question then becomes what "depths" should the
> conversion in P2 be checking?  If the normal block-nesting level was
> used (where X is 1, Y is 2, and Z is 3), then Z would become evaluated
> as "too deep", since A would be 2 and Z would be 3, and you would get
> an erroneous program error doing the conversion.
>
> So you can tweak things to say that in these special cases, you pass
> the *lower* of either the actual object depth or P1 itself.  So, in
> this case, now Z will pass the dynamic check since instead of getting
> the depth of Z, P2 gets the depth of P1 (since 1<3).  Now you can nest
> the declarative blocks a billion levels deep, and the proposed model
> still adheres to the LRM.

Ah, this is a nice example with a good explanation.
Thank you very much! Now I think I understand why this rule exists and 
how it is working.

> Again, it's important to stress that this is just one special case of
> one special part of just one possible implementation of one
> special-case language feature from twenty years ago, and that none of
> this should weigh heavily on your mind when learning or using Ada.

Does that mean that a compiler writer is allowed to implement this rule, 
but it is not strictly necessary?

I tried to compile and run your example. I replaced
"type T is ...;" by "type T is new Integer;"
and "type A is access T;" by "type A is access all T;"
to get it compiled (with Gnat 4.9 on Debian Jessie 8.0 amd64).
It runs but "P1(Z'Access);" raises Program_Error.

If I understand you correctly this is not a compiler bug and this 
optional rule was just not implemented in Gnat, right?

Regards,

Michael

Re: Access parameters and accessibility

[sbelmont700]

On Wednesday, December 17, 2014 9:30:57 AM UTC-5, Michael B. wrote:
> 
> If I understand you correctly this is not a compiler bug and this 
> optional rule was just not implemented in Gnat, right?
> 

It sounds very much like a compiler bug; regardless of the mechanism that the compiler writer chooses to use to implement the rules of the language, it must in fact implement them correctly and completely (i.e. all those conversions should pass, no matter if they use the model proposed in the paper, or something else entirely).  GNAT is infamous for blowing all sorts of dynamic accessibility checks, many much more common than this convoluted edge case, so it's not altogether shocking.  But as others have said, the rules are getting so insane that its tough to even know what the correct behavior ought to be, let alone whether a compiler does it (or could ever actually hope to do it at all).

Hopefully someone who knows more will verify what that code should actually do.

-sb

Re: Access parameters and accessibility

[Adam Beneschan]

On Wednesday, December 17, 2014 6:30:57 AM UTC-8, Michael B. wrote:

> Does that mean that a compiler writer is allowed to implement this rule, 
> but it is not strictly necessary?
> 
> I tried to compile and run your example. I replaced
> "type T is ...;" by "type T is new Integer;"
> and "type A is access T;" by "type A is access all T;"
> to get it compiled (with Gnat 4.9 on Debian Jessie 8.0 amd64).
> It runs but "P1(Z'Access);" raises Program_Error.
> 
> If I understand you correctly this is not a compiler bug and this 
> optional rule was just not implemented in Gnat, right?

I don't think there are any "optional" accessibility rules.

                               -- Adam
           

Re: Access parameters and accessibility

[Randy Brukardt]

"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnm92al9.nrc.lithiumcat@nat.rebma.instinctive.eu...
...
> Am I doing something danegerous here?
> Should I try to find another pattern to achieve the same effects?
>
> From what I understood, here accessibility is statically known to be
> fine, isn't it? Or is there a trap hidden in there?

I think it is *supposed* to be statically fine. Whether the actual rules 
have that effect is unclear. Most likely, implementers will follow the 
intent rather than the actual rules (but since there have been a number of 
cases to the contrary, I wouldn't assume that unconditionally -- always 
check). (And no, I'm not going to try to figure this out for you, I try to 
minimize trips into this area.)

As always with accessibility, whenever we look at it in detail, someone 
finds a problem where the rules aren't quite what we want. That's why it's 
known as the "Heart of Darkness".

                                             Randy.

Re: Access parameters and accessibility

[Randy Brukardt]

"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnm92hsh.nrc.lithiumcat@nat.rebma.instinctive.eu...
> On 2014-12-17, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Wed, 17 Dec 2014 07:02:56 +0000 (UTC), Natasha Kerensikova wrote:
>>
>>> Now you got me really worried, because I thouhgt access discriminants
>>> were safe. It was under that assumption that I actually started to
>>> really like them.
>>>
>>> More specifically, the pattern I caught myself using a lot looks like
>>> the following:
>>>
>>>    type Preprocessed_Data (Input_Data : access Input_Data_Type) is 
>>> record
>>
>> not null access?
>
> I tought access discriminants were not allowed to be null.
> Has that changed?
> Or do you advise "not null access" to make it explicit?

Explicit is always better, regardless of the rules.

Ada 95 did not define null for anonymous access types, but all more recent 
versions of Ada do. The only implicit restriction against null that I 
remember in modern Ada is for dispatching anonymous access parameters. See 
3.10(13.1/2). Ahh, yes, AARM 3.10(26.c/2) says:

Inconsistences with Ada 95
Access discriminants and noncontrolling access parameters no longer exclude 
null. A program which passed null to such an access discriminant or access 
parameter and expected it to raise Constraint_Error may fail when compiled 
with Ada 2005. One hopes that there no such programs outside of the ACATS. 
(Of course, a program which actually wants to pass null will work, which is 
far more likely.)

Moral: If you're programming for Ada 2005 or later, always use a null 
exclusion when that makes sense. (It's even a good idea on controlling 
parameters, we would have preferred to require it but that would have been 
severely incompatible with Ada 95.)

                                Randy.

Re: Access parameters and accessibility

[Randy Brukardt]

"Adam Beneschan" <adambeneschan@gmail.com> wrote in message 
news:eea29e4c-921a-467c-8007-80e80eda3507@googlegroups.com...
On Tuesday, December 16, 2014 11:46:59 AM UTC-8, Michael B. wrote:
...
>I'm sure Randy was being tongue-in-cheek when he said "get better 
>libraries".

Ahh, no.

...
>For one thing, you'd have to get better libraries than the libraries Ada 
>provides,
>because Ada defines some subprograms with anonymous access 
>parameters--namely
>Ada.Tags.Generic_Dispatching_Constructor, Ada.Execution_Time.Timers.Timer, 
>and >Read|Write_Exception_Occurrence in Ada.Exceptions. Also, the stream 
>attribute
>subprograms ('Read, 'Write, etc.) all have anonymous access parameters, and 
>you
>have to *write* a subprogram that has an anonymous access parameter in 
>order to
>use it as the stream subprogram for a type.  Quelle horreur!

Yup. With the exception of timers, all of the others stem directly from the 
mistake of using an anonymous access for streams. And *that* stems from the 
mistake of not allowing "in out" parameters for functions (as Input is a 
function).

Ergo, in Ada 2012 you would write those as "in out Root_Stream_Type'Class". 
And one should think of them as exactly that. (It's too late to fix this 
mistake, sadly.)

In the case of Timer, (a) no one ever uses this feature, and (b) I have no 
idea why this just isn't

type Timer (T : Ada.Task_Identification.Task_Id) is tagged limited private;

I have no idea who has an aliased Task_Id laying around anyway. That seems 
amazingly hard to use for no value whatsoever. I suspect it was something 
else originally and it never got changed sensibly.

>Anyway, I think you can avoid defining new subprograms that take anonymous 
>access
>parameters (except where needed for streams, or for 
>Generic_Dispatching_Constructor)
>and not add to the problem, but I don't see any value in avoiding existing 
>libraries.

Well, if you could tell a-priori if "access" was used as a stand-in for "in 
out", then it would be OK. In that case, the only use of the "access" is to 
dereference it.

But it if is actually used as an access type (with the access value being 
copied somewhere), then you have trouble (with random Program_Errors and a 
need to avoid passing local objects). It's possible in Ada 2012 to write a 
precondition for this case, but of course that's not required (and surely is 
not found in existing libraries), so the possibility doesn't help much.

Since you can't tell these cases apart (and the first is never necessary in 
Ada 2012 anyway, with the possible exception of foreign conventions), it's 
best to just avoid the feature. Especially as "access" is more expensive 
than "in out" because of the dynamic accessibility checking overhead (which 
exists regardless of whether it is ever used). Libraries should reflect this 
(moreso as Ada 2012 gets adopted more).

                                Randy.

Re: Access parameters and accessibility

[Shark8]

On 17-Dec-14 00:02, Natasha Kerensikova wrote:
> Now you got me really worried, because I thouhgt access discriminants
> were safe. It was under that assumption that I actually started to
> really like them.

Discriminants that are an access-type have exactly the scope-validity of 
the type, and therefore exhibit /exactly/ the "perfect fit" for 
accessibility.

In short: use them to your heart's content.

Re: Access parameters and accessibility

[Robert A Duff]

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

> Yup. With the exception of timers, all of the others stem directly from the 
> mistake of using an anonymous access for streams. And *that* stems from the 
> mistake of not allowing "in out" parameters for functions (as Input is a 
> function).

Yes, and *that* stems from the unfortunate fact that 'out' parameters
don't work like function results (for composites).

> Ergo, in Ada 2012 you would write those as "in out Root_Stream_Type'Class". 
> And one should think of them as exactly that. (It's too late to fix this 
> mistake, sadly.)

Yes.

> In the case of Timer, (a) no one ever uses this feature, and (b) I have no 
> idea why this just isn't
>
> type Timer (T : Ada.Task_Identification.Task_Id) is tagged limited private;

Because Task_Id is a private type, and unfortunately you can't have
discriminants of private type in Ada.

> But it if is actually used as an access type (with the access value being 
> copied somewhere), then you have trouble (with random Program_Errors and a 
> need to avoid passing local objects). It's possible in Ada 2012 to write a 
> precondition for this case, but of course that's not required (and surely is 
> not found in existing libraries), so the possibility doesn't help much.

Not sure what you mean.  Could you show an example of such a
precondition?

- Bob

Re: Access parameters and accessibility

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccwq5prd0n.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
>> In the case of Timer, (a) no one ever uses this feature, and (b) I have 
>> no
>> idea why this just isn't
>>
>> type Timer (T : Ada.Task_Identification.Task_Id) is tagged limited 
>> private;
>
> Because Task_Id is a private type, and unfortunately you can't have
> discriminants of private type in Ada.

Ah yes, another language bug that we had to work around. I'm sure that by 
Ada 2045 discriminants will be allowed to be any type. ;-)

> But it if is actually used as an access type (with the access value being
>> copied somewhere), then you have trouble (with random Program_Errors and 
>> a
>> need to avoid passing local objects). It's possible in Ada 2012 to write 
>> a
>> precondition for this case, but of course that's not required (and surely 
>> is
>> not found in existing libraries), so the possibility doesn't help much.
>
> Not sure what you mean.  Could you show an example of such a
> precondition?

We extended membership checks to do accessibility checking in Ada 2005. (One 
of the things near the top of my ACATS priority list is to create a couple 
of tests for that feature.)

So if you have something like (stolen from Claw):

     type Any_Window_Type is access all Root_Window_Type'Class;

then you could write:

     procedure Show (Win : access Root_Window_Type; How : in 
Show_Window_Kind)
         with Pre => Win in Any_Window_Type;

and that will fail if Win is not convertable to Any_Window_Type, including 
accessibility. (See 4.5.2(30.3/4)). [I think we put this feature in in 
response to a comment/e-mail made by one Bob Duff. But it was a long time 
ago, so I might be wrong about that.]

The presence of such a precondition clearly shows that we're going to make 
an accessibility check in the body of the routine, and thus one had better 
not pass a local object. Of course if you just have:

     procedure Show (Win : access Root_Window_Type; How : in 
Show_Window_Kind);

you don't know that there isn't any conversion. Indeed, I don't know of any 
way to declare that no conversion happens (you can't really write that there 
are no restrictions). I suppose Pre => True sort of has that effect, if it's 
really meant and not just a short-hand for I-dunno!

Of course, the actual Claw specification is:
     procedure Show (Win : in Root_Window_Type; How : in Show_Window_Kind);
and we use 'Unchecked_Access and finalization to ensure that there's no 
dangling pointer problems for the conversion. Which is better still, IMHO 
(as no restrictions are needed).

                                            Randy.

Re: Access parameters and accessibility

[Shark8]

On 17-Dec-14 18:17, Randy Brukardt wrote:
> Ah yes, another language bug that we had to work around. I'm sure that by
> Ada 2045 discriminants will be allowed to be any type.

Hm, I wonder about discriminated enumerations... ;)

Re: Access parameters and accessibility

[Dmitry A. Kazakov]

On Wed, 17 Dec 2014 17:18:59 -0600, Randy Brukardt wrote:

> Ergo, in Ada 2012 you would write those as "in out Root_Stream_Type'Class". 
> And one should think of them as exactly that. (It's too late to fix this 
> mistake, sadly.)

But stream attributes are hard-wired anyway. Why not to add ones with the
in-out stream parameter? One one can be overridden (and so defines
another), any can be used? It is similar to how "=" and "/=" are treated.

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

Re: Access parameters and accessibility

[Michael B.]

On 12/17/14 17:03, Adam Beneschan wrote:
> I don't think there are any "optional" accessibility rules.

Do you think it's a compiler bug?

Re: Access parameters and accessibility

[Michael B.]

On 12/17/14 16:41, sbelmont700@gmail.com wrote:
> It sounds very much like a compiler bug; regardless of the mechanism
> that the compiler writer chooses to use to implement the rules of the
> language, it must in fact implement them correctly and completely
> (i.e. all those conversions should pass, no matter if they use the
> model proposed in the paper, or something else entirely).

That makes sense. So it seems my misunderstanding came from too much 
trust in a compiler...

Re: Access parameters and accessibility

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:vxaluu2b5jkb.10f4p234jkqzz.dlg@40tude.net...
> On Wed, 17 Dec 2014 17:18:59 -0600, Randy Brukardt wrote:
>
>> Ergo, in Ada 2012 you would write those as "in out 
>> Root_Stream_Type'Class".
>> And one should think of them as exactly that. (It's too late to fix this
>> mistake, sadly.)
>
> But stream attributes are hard-wired anyway. Why not to add ones with the
> in-out stream parameter? One one can be overridden (and so defines
> another), any can be used? It is similar to how "=" and "/=" are treated.

Might work, but it would be pretty messy and unclear (to most) that it would 
buy enough for the pain. Probably better to just plan on that in Ada++. :-)

                                 Randy.

Re: Access parameters and accessibility

[Randy Brukardt]

I said:
...
> We extended membership checks to do accessibility checking in Ada 2005.

Actually, that was in Ada 2012, which I could have found out by reading the 
AARM at the bottom of 4.5.2 more closely. Sorry about the confusion.

                                         Randy.

Re: Access parameters and accessibility

[Michael B.]

Thank you to all of you for your helpful answers!
This whole accessibility thing is now much clearer to me.

Regards,

Michael