Version 1.4 of ais/ai-00341.txt

Unformatted version of ais/ai-00341.txt version 1.4
Other versions for file ais/ai-00341.txt

!standard 13.14 (15) 03-11-08 AI95-00341/02
!class binding interpretation 03-08-01
!status Amendment 200Y 04-07-02
!status WG9 approved 04-11-18
!status ARG Approved 8-0-1 04-06-14
!status work item 03-08-01
!status received 03-07-14
!qualifier Omission
!priority Low
!difficulty Easy
!subject Primitive subprograms are frozen with a tagged type

!summary

All primitive subprograms of a tagged type are frozen when the type is frozen.

!question

The test developed to test 13.14(8.1/1) brings up an interesting question. It appears that the language requires that the generation of a tag be delayed after the freezing of the tagged type, as that does not freeze the dispatching subprograms. Consider:

package P1 is

type Ctrl is new Controlled with record C : String (1 .. 3); end record;

procedure Initialize (C : in out Ctrl); procedure Adjust (C : in out Ctrl); procedure Finalize (C : in out Ctrl);

X : Ctrl := (Controlled with C => "abc"); -- Freezes Ctrl.

pragma Import (Ada, Finalize, ...); -- OK, not frozen yet. for Finalize'Address use 16#4567#; -- OK. end P1;

Finalize is not frozen by the freezing of the type Ctrl, and it isn't frozen by 13.14(8.1/1) (because there is no implicit call to it here). The recommended level of support for address clauses requires that the address clause be accepted (13.3(17)), presuming of course that the address expression is valid for the implementation.

However that means that the tag (which presumably contains the addresses of the subprograms) cannot be built until after all of the dispatching subprograms are frozen -- not at the point where the type is frozen. That seems to violate the principles of the language design as noted in AARM 3.9.2(13.d).

So, is 3.9.2(13.d) wrong? (No.)

!recommendation

(See wording.)

!wording

Add after 13.14(15):

At the place where a specific tagged type is frozen, the primitive subprograms of the type are frozen.

!discussion

AARM 3.9.2(13.d) and 13.14(1.f) both refer to the principle that all of the details of a tagged type are known when it is frozen. But that is only true if the primitive subprograms also are frozen at that point.

This is an important language design principle, so we adopt an additional freezing rule to preserve it.

It is not legal to declare any additional operations after the freezing of the type anyway, so this change will not have any effect on what can be declared.

With this rule in place, it is not necessary to track implicit calls to the controlled operations Initialize and Adjust for the purposes of freezing. This should simplify implementations.

At least one existing Ada implementation freezes primitive operations when the type is frozen.

!corrigendum 13.14(15)

Insert after the paragraph:

At the place where a subtype is frozen, its type is frozen. At the place where a type is frozen, any expressions or names within the full type definition cause freezing; the first subtype, and any component subtypes, index subtypes, and parent subtype of the type are frozen as well. For a specific tagged type, the corresponding class-wide type is frozen as well. For a class-wide type, the corresponding specific type is frozen as well.

the new paragraph:

At the place where a specific tagged type is frozen, the primitive subprograms of the type are frozen.

!ACATS test

An ACATS test could be constructed to test this. It could easily be done using confirming Convention pragmas, but that is a virtually useless thing to do for a tagged primitive operation (which has to have the convention of the type anyway). Using an address clause as in the question would be possible, but it would be system-dependent.

!appendix


From: Randy Brukardt
Sent: Monday, July 14, 2003  7:48 PM

The test developed to test 13.14(8.1/1) brings up an interesting question.
It appears that the language requires that the generation of a tag be
delayed after the freezing of the tagged type, as that does not freeze the
dispatching subprograms. Consider:

    package P1 is

      type Ctrl is new Controlled with
          record
              C : String (1 .. 3);
          end record;

      procedure Initialize (C : in out Ctrl);
      procedure Adjust (C : in out Ctrl);
      procedure Finalize (C : in out Ctrl);

      X : Ctrl := (Controlled with C => "abc"); -- Freezes Ctrl.

      pragma Import (Ada, Finalize, ...); -- OK, not frozen yet.
      for Finalize'Address use 16#4567#; -- OK.
    end P1;

Finalize is not frozen by the freezing of the type Ctrl, and it isn't frozen
by 13.14(8.1/1) (because there is no implicit call to it here). The
recommended level of support for address clauses requires that the address
clause be accepted (13.3(17)), presuming of course that the address
expression is valid for the implementation.

However that means that the tag (which presumably contains the addresses of
the subprograms) cannot be built until after all of the dispatching
subprograms are frozen -- not at the point where the type is frozen. That
seems to violate the principles of the language design as noted in AARM
3.9.2(13.d).

So, is 3.9.2(13.d) wrong? Or do we need to extend the freezing rules a bit
more?

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

From: Tucker Taft
Sent: Monday, July 14, 2003  9:40 PM

Although I am not sure I fathom all the implications,
I would agree that freezing a tagged type ought to
freeze all of its primitive subprograms.
You can't declare any new ones after the type has
been frozen, so it seems a relatively small step
to freeze the existing ones as well.

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

Questions? Ask the ACAA Technical Agent