Version 1.7 of ais/ai-00313.txt

Unformatted version of ais/ai-00313.txt version 1.7
Other versions for file ais/ai-00313.txt

!standard 8.3 (16)          02-09-27 AI95-00313/01
!standard 8.3 (17)
!class amendment 02-09-27
!status No Action (8-0-2) 02-10-11
!status work item 02-09-27
!status received 02-09-20
!priority Low
!difficulty Easy
!subject Self-reference in subprogram access
!summary
The name of an access-to-subprogram type can be used in the declaration of the type.
!problem
It is very inconvinient to write an access-to-subprogram type which takes a parameter of the type itself.
!proposal
Add after 8.3(17):
For an access-to-subprogram type, the declaration is hidden from all visibility only until the reserved keyword access;
!discussion
For example:
type Chaining_Procedure is access procedure (...<other parameters>...; Next_Proc : Chaining_Procedure);
This is illegal by 8.3(16). Declaring Chaining_Procedure as an incomplete type prior to this doesn't help, because of 8.3(19).
The best workaround seems to be to add a new type:
type Chaining_Procedure_2; type Chaining_Procedure is access procedure
(...<other parameters>...; Next_Proc : Chaining_Procedure_2);
type Chaining_Procedure_2 is new Chaining_Procedure;
which requires the use of type conversions between the types.
!example
!ACATS test
An ACATS C-Test should be created.
!appendix

!topic Self-reference in subprogram access
!reference RM95 8.3(16-18), 3.10
!from Adam Beneschan 09-20-02
!discussion

Is there any reason why this should be illegal?

   type Chaining_Procedure is access procedure
            (...<other parameters>...; Next_Proc : Chaining_Procedure);

This is illegal by 8.3(16) [and declaring Chaining_Procedure as an
incomplete type prior to this doesn't help, because of 8.3(19)].
However, someone may want to do something like this, and there aren't
any implementation problems that I can think of.

(The best workaround I can think of is to add a new type:

   type Chaining_Procedure_2;
   type Chaining_Procedure is access procedure
            (...<other parameters>...; Next_Proc : Chaining_Procedure_2);
   type Chaining_Procedure_2 is new Chaining_Procedure;

which may necessitate a type conversion in some cases.)

Anyway, this may not be a high priority, but it seems harmless to me
to add another exception after 8.3(17) that for an
access-to-subprogram type declaration, the declaration is hidden from
all visibility only until the reserved word "access".

****************************************************************

From: Randy Brukardt
Sent: Friday, September 27, 2002  3:10 PM

I do agree its harmless, but even so, its additional work. (Figuring out how
to change 'hidden from all visibility' is non-trivial in Janus/Ada, at
least). Given that, I'd like to know if anyone has run into this problem in
practice. If not, perhaps it is not worth the effort to change even if it
would be relatively easy.

****************************************************************

From: Adam Beneschan
Sent: Wednesday, November  5, 2003  11:41 AM

Back in September 2002, we had discussed the possibility of allowing
the declaration of an access-to-subprogram type T to refer to T in the
subprogram parameters or return type:

[Adam Beneschan:]
>
> Is there any reason why this should be illegal?
>
>    type Chaining_Procedure is access procedure
>             (...<other parameters>...; Next_Proc :
>             Chaining_Procedure);
>
> This is illegal by 8.3(16) [and declaring Chaining_Procedure as an
> incomplete type prior to this doesn't help, because of 8.3(19)].
> However, someone may want to do something like this, and there aren't
> any implementation problems that I can think of.
>
> (The best workaround I can think of is to add a new type:
>
>    type Chaining_Procedure_2;
>    type Chaining_Procedure is access procedure
>             (...<other parameters>...; Next_Proc :
>    Chaining_Procedure_2);
>    type Chaining_Procedure_2 is new Chaining_Procedure;
>
> which may necessitate a type conversion in some cases.)
>
> Anyway, this may not be a high priority, but it seems harmless to me
> to add another exception after 8.3(17) that for an
> access-to-subprogram type declaration, the declaration is hidden from
> all visibility only until the reserved word "access".

[Randy Brukardt:]
>
> I do agree its harmless, but even so, its additional work. (Figuring
> out how to change 'hidden from all visibility' is non-trivial in
> Janus/Ada, at least). Given that, I'd like to know if anyone has run
> into this problem in practice. If not, perhaps it is not worth the
> effort to change even if it would be relatively easy.

It appears that someone has now run into this problem; see the thread
"Problem with Self-Referential Access-To-Subprogram Type" on
comp.lang.ada.  Here's the source the poster (a self-described "Ada
newbie") was trying to use:

    package Test is
       --  A little ADT:
       type Test_Type is tagged private;
       function Get_Dummy (Tester : Test_Type) return Integer;
       procedure Set_Dummy (Tester : in out Test_Type; Dummy : in Integer);

       --  An access-to-function type that works (but Tester is read-only):
       type State1;
       type State1 is access function (Tester : Test_Type'Class)
                                      return State1;
       --  An access-to-procedure type that doesn't work:
       type State2;
       type State2 is access procedure (Tester : in out Test_Type'Class;
                                        Resultant_State : out State2);
       --                premature use of "State2" right here ^
    private
       type Test_Type is
         tagged record
            Dummy : Integer;
         end record;
    end Test;

(The declaration of State1 should not have compiled.)

****************************************************************

From: Dan Eilers
Sent: Tuesday, October 26, 2004  8:07 AM

The ARG minutes for AI-382 say:

> Should this be allowed in access-to-subprogram? That seems OK.
> ...
> Replace "general access type" by "access-to-object type"; add "a parameter
> of an access-to-subprogram" as another place it is allowed to be a type.

This is the same question that was raised in AI-313 (with regard to
named access types), and in that case it was voted no-action.

Now that allowing this has been approved for AI-382, I think AI-313
should be revisited, and the corresponding restriction lifted for
named access types, since the restriction serves no purpose.

****************************************************************

From: Dan Eilers
Sent: Monday, November 15, 2004  3:21 PM

Pascal wrote:

> Other than a superficial similarity, these AIs have very little to do with
> each other.  313 was given due consideration by the ARG, and was voted No
> Action.  No new technical information has surfaced that could cause the
> ARG to change its decision.  The reason for introducing 382 is that it
> fixes a problem that would have been ubiquitous, and would have made
> anonymous access types unusable in practice.  313 is on the other hand a
> pathological cornercase, and doesn't deserve more discussion.


I may have misunderstood the ARG minutes.
My understanding was that we would have:

 type T1 is
    record
        data: access procedure (Next_Proc : T1); -- legal by AI-382??
    end record;

 type T2 is access procedure (Next_Proc : T2);  -- illegal by AI-313

which is what seemed inconsistent.
But the AI as written makes T1 illegal, so with that interpretation
there is no inconsistency.

****************************************************************

From: Tucker Taft
Sent: Monday, November 15, 2004  8:30 PM

I'm not sure whether we ultimately agreed to allow
the example you gave, but even if we did, I don't
see the inconsistency.  We don't generally allow
a name to be referenced in its own declaration.
We make a few exceptions, in particular for packages
and for record types, but we don't allow, for example:

     type T2 is access T2;

or

     type T1 is range T1'First .. T1'Last;

As an implementor, I have enough trouble with:

     type Q is access procedure(X : incomplete_type);

Supporting "type Q is access procedure(X : Q);" seems
gratuitously difficult with little benefit.

****************************************************************

Questions? Ask the ACAA Technical Agent