AI22-0132-1

!standard 4.10(18/5)                                    25-03-24  AI22-0132-1/02

!standard 4.10(19/5)

!standard 4.10(21/6)

!standard 4.10(24/5)

!class binding interpretation 25-03-21

!status Amendment 1-2022  25-03-21

!status WG9 Approved 25-07-18

!status ARG Approved by Letter Ballot 14-0-1 25-04-14

!status work item 25-03-21

!status received 25-03-21

!submitter Christoph Grein

!assigned author Tucker Taft

!priority Low

!difficulty Easy

!qualifier Clarification

!subject Order for displaying components by default Put_Image

!summary

The description of the order in which components are displayed by the default implementation of Put_Image should be clarified, and not refer to T'Write.

!issue

The use of the term "canonical order" in the description of Put_Image is misleading (4.10(18/5)), since in the other two places it is used (T'Write and Generalized Loop Iteration) it is related to the issue of multidimensional arrays, and whether they are iterated in column-major or row-major order, which is determined by whether or not the Fortran convention has been specified. For Put_Image, multidimensional arrays are intended to use nested aggregate notation, so this issue of row-major vs. column-major order is irrelevant. Thus, for arrays at least, canonical order should not be referenced.

Furthermore, the reference to T'Write in 4.10(18/5) is not particularly helpful. The paragraph in general seems superfluous, as the three places below the paragraph where it might be relevant (4.10(19/5), 4.10(21/6), and 4.10(24/5)) could describe the order more simply (and in the case of the array description, has to describe it separately).

Should we clarify the description of the order that components are displayed by the default implementation of Put_Image? (Yes.)

!recommendation

Delete paragraph 4.10(18/5) and describe the order directly in 4.10(19/5), 4.10(21/5) and 4.10(24/5).

The existing AI, AI22-0119-1, which attempts to centralize the definition of "canonical order", should be updated to account for these changes to 4.10.

!wording

Delete 4.10(18/5), which currently says:

• If the default implementation of Put_Image writes components, the order in which components are written is the same canonical order in which components of a composite type T are written out by the default implementation of T'Write. [Redundant: This is also the order that is used in determining the meaning of a positional aggregate of type T.]

Modify 4.10(19/5):

• For an array type T, the default implementation of T'Put_Image generates an image based on named (not positional) array aggregate syntax (with '[' and ']' as the delimiters) using calls to the Put_Image procedures of the index type(s) and the element type to generate images for values of those types. {The components are written in increasing index order at each level, using a nested syntax for a multidimensional array, as in a multidimensional array aggregate.}

Modify 4.10(21/6):

• For a record type (or, as indicated above, certain composite derived types), or a protected type, the default implementation of T'Put_Image generates an image based on named (not positional) record aggregate syntax (except that for a protected type, the initial left parenthesis is followed by "PROTECTED with "). Component names are displayed in upper case, following the rules for the image of an enumeration value. Component values are displayed via calls to the Put_Image procedure of the component type.{ Components are displayed in the order they occur within the declarative region of the type (see 8.1 and 3.4).}

Modify 4.10(24/5):

• For a discriminated task type, the default implementation of T'Put_Image also includes discriminant values{, in the order they occur within the known_discriminant_part}, as in:

!discussion

The existing AI (AI22-0119-1) which tried to fix this same problem while also centralizing the definition of "canonical order" was felt to be too much change for a corrigendum, so we have separated out the "bug fix" of that AI into this AI, and will leave the centralizing of the definition of "canonical order" to an amendment to the standard.

This AI now tries to do the minimum to clarify that the order of components within the default implementation of Put_Image is based on order of occurrence within the declarative region of the type, and doesn't really relate to the term "canonical order". That term was introduced to handle Fortran-style multidimensional arrays, which occur in column-major rather than row-major order in memory, but Put_Image for arrays actually uses nested aggregate notation instead, so the distinction of column-major vs. row-major is irrelevant (and it would be wrong to refer to it).

!corrigendum 4.10(18/5)

@ddel

If the default implementation of Put_Image writes components, the order in which components are written is the same canonical order in which components of a composite type T are written out by the default implementation of T'Write. This is also the order that is used in determining the meaning of a positional aggregate of type T.

!corrigendum 4.10(19/5)

@drepl

For an array type T, the default implementation of T'Put_Image generates an image based on named (not positional) array aggregate syntax (with '[' and ']' as the delimiters) using calls to the Put_Image procedures of the index type(s) and the element type to generate images for values of those types.

@dby

For an array type T, the default implementation of T'Put_Image generates an image based on named (not positional) array aggregate syntax (with '[' and ']' as the delimiters) using calls to the Put_Image procedures of the index type(s) and the element type to generate images for values of those types. The components are written in increasing index order at each level, using a nested syntax for a multidimensional array, as in a multidimensional array aggregate.

!corrigendum 4.10(21/6)

@drepl

For a record type (or, as indicated above, certain composite derived types), or a protected type, the default implementation of T'Put_Image generates an image based on named (not positional) record aggregate syntax (except that for a protected type, the initial left parenthesis is followed by @fc{"PROTECTED with "}). Component names are displayed in upper case, following the rules for the image of an enumeration value. Component values are displayed via calls to the Put_Image procedure of the component type.

@dby

For a record type (or, as indicated above, certain composite derived types), or a protected type, the default implementation of T'Put_Image generates an image based on named (not positional) record aggregate syntax (except that for a protected type, the initial left parenthesis is followed by @fc{"PROTECTED with "}). Component names are displayed in upper case, following the rules for the image of an enumeration value. Component values are displayed via calls to the Put_Image procedure of the component type. Components are displayed in the order they occur within the declarative region of the type (see @ref{8.1} and @ref{3.4}).

!corrigendum 4.10(24/5)

@drepl

For a discriminated task type, the default implementation of T'Put_Image also includes discriminant values, as in:

@dby

For a discriminated task type, the default implementation of T'Put_Image also includes discriminant values, in the order they occur within the @fa{known_discriminant_part}, as in:

!ACATS test

Any new or existing ACATS tests for Put_Image should be checked to be sure they do not expect multidimensional arrays to be displayed in a flattened row-major or column-major order, but rather use nested aggregate syntax, as clarified in 4.10(19) above.

!appendix

This issue was identified during the discussion of ARG GitHub issue # 85.  This AI was split off of AI22-0119-1 as an AI that could be reasonably included in a Corrrigendum rather than an Amendment.