!standard 4.10(3.1/5) 19-03-11 AI12-0320-1/03 !standard 4.10(6/5) !standard 5.5.3(11/5) !standard C.1(2) !standard C.3.2(24/3) !standard E.2.1(7/4) !standard E.2.1(7.1/4) !class binding interpretation 19-03-06 !status Amendment 1-2012 19-03-06 !status ARG Approved 10-0-0 19-03-11 !status work item 19-03-06 !status received 19-03-05 !priority Low !difficulty Easy !qualifier Clarification !subject Changes from the RM review !summary Various wording changes are made to clarify the Standard. !question (1) E.2.1(7/4) is confusing: ... nor a type with a part that is of a task type or protected type with entry_declarations. This can be read two ways as shown by the parens below: ... nor a type with a part that is of a ((task type or protected type) with entry_declarations). or ... nor a type with a part that is of a ((task type) or (protected type with entry_declarations)). Should this be clarified? (Yes.) (2) Put_Image is defined as (in 4.10(3.1/5)): procedure S'Put_Image (Arg : in T; Stream : not null access Ada.Streams.Root_Stream_Type'Class); Normally, I/O operations (streaming, text io, and so on) put the stream or file parameter first. Should these parameters be reversed? (Yes.) (3) 5.5.3(11/5) ends with "This rule is an overloading rule." But this seem unnecessary; *every* rule in a Name-Resolution Rules section is an overloading rule by definition. Should this be deleted? (Yes.) (4) 5.5.3(14/5) is a Legality Rule about abstract subprograms. We made an effort to put all of the abstract rules into 3.9.3. Should this rule be given there? (Yes.) (5) The requirements in C.1(2) seem too strong. There is a requirement to provide implementation-defined attributes to provide access to Ada entities for machine code access. However, this seems like overspecification. If language-defined attributes (such as Address) are enough to provide the needed access, then the requirement seems to require defining unneeded things. Moreover, it seems to require defining more than one, so defining only a single attribute also seems to fail the requirement. Finally, if an implementation uses intrinsic subprograms to provide machine code access, which is allowed by this requirement, then access to Ada entities would be by parameter passing, which hardly seems to need anything beyond the usual facilities. Should this requirement be reworded? (Yes.) (6) C.3.2(24/3) says: If the Ceiling_Locking policy (see D.3) is in effect, the implementation shall document the default ceiling priority assigned to a protected object that contains a protected procedure that specifies either the Attach_Handler or Interrupt_Handler aspects, but does not specify the Interrupt_Priority aspect. As phrased, it seems that there is a documentation requirement only if the ceiling locking policy is in effect. Is that intended? (No.) !recommendation (1) The original wording makes it clear that the second interpretation is intended. Adding more connector words only helps a tiny bit, so the recommendation is to change this into a list of sub-bullets (and we can include the following bullet in that rewrite as well). (2) Put_Image should have parameters in the same order as Write. (3) Delete the redundant text. (4) Put the rule into 3.9.3, and leave the existing copy, marked as Redundant. (5) Work the requirement in terms of providing access and avoid mentioning how that might be done. (6) Reorder this paragraph. !wording Replace E.2.1(7/4-7.1/4) with: * it shall not contain a library-level declaration: * of an access type that designates a class-wide type; * of a type with a part that is of a task type; * of a type with a part that is of a protected type with entry_declarations; or * that contains a name that denotes a type declared within a declared-pure package, if that type has a part that is of an access type; for the purposes of this rule, the parts considered include those of the full views of any private types or private extensions. [Editor's note: Put the AARM notes after the appropriate bullet.] Replace 4.10(3.1/5) with: procedure S'Put_Image (Stream : not null access Ada.Streams.Root_Stream_Type'Class; Arg : in T); Replace 4.10(6/5) with: procedure Scalar_Type'Put_Image (Stream : access Ada.Streams.Root_Stream_Type'Class; Arg : Scalar_Type) is begin Wide_Wide_String'Write (Stream, ); end Scalar_Type'Put_Image; Delete "This rule is an overloading rule (see 8.6)." from the end of 5.5.3(11/5). Add after 3.9.3(7): If the name or prefix given in an iterator_procedure_call (see 5.5.3) denotes an abstract subprogram, the subprogram shall be a dispatching subprogram. Mark 5.5.3(14/5) as redundant. Modify C.1(2): The implementation shall support machine code insertions (see 13.8) or intrinsic subprograms (see 6.3.1) (or both). {The implementation}[Implementation-defined attributes] shall [be provided to] allow the use of Ada entities as operands {for such machine code insertions or intrinsic subprograms}. AARM Discussion: Ada entities could be used as operands in machine code insertions and/or intrinsic subprograms using language-defined attributes (such as address), implementation-defined attributes, or could be directly allowed. Modify C.3.2(24/3): {The implementation shall document, when}[If] the Ceiling_Locking policy (see D.3) is in effect, [the implementation shall document ]the default ceiling priority assigned to a protected object that contains a protected procedure that specifies either the Attach_Handler or Interrupt_Handler aspects, but does not specify the Interrupt_Priority aspect. !discussion For (2), the closest existing routine is S'Write, and the specification should be similar. Otherwise, remembering the order of parameters would quickly become maddening. For (3), it is particularly weird that the third rule out of four makes this statement, when it equally applies to all four rules. !corrigendum 3.9.3(7) @dinsa A call on an abstract subprogram shall be a dispatching call; [nondispatching calls to an abstract subprogram are not allowed.] @dinst If the @fa or @fa given in an @fa (see 5.5.3) denotes an abstract subprogram, the subprogram shall be a dispatching subprogram. !corrigendum 4.10(0) @dinsc This is a new clause, so just force a conflict; the change is found in the conflict file. !corrigendum 5.5.3(0) @dinsc This is a new clause, so just force a conflict; the change is found in the conflict file. !corrigendum C.1(2) @drepl The implementation shall support machine code insertions (see 13.8) or intrinsic subprograms (see 6.3.1) (or both). Implementation-defined attributes shall be provided to allow the use of Ada entities as operands. @dby The implementation shall support machine code insertions (see 13.8) or intrinsic subprograms (see 6.3.1) (or both). The implementation shall allow the use of Ada entities as operands for such machine code insertions or intrinsic subprograms. !corrigendum C.3.2(24/3) @drepl If the Ceiling_Locking policy (see D.3) is in effect, the implementation shall document the default ceiling priority assigned to a protected object that contains a protected procedure that specifies either the Attach_Handler or Interrupt_Handler aspects, but does not specify the Interrupt_Priority aspect. @dby The implementation shall document, when the Ceiling_Locking policy (see D.3) is in effect, the default ceiling priority assigned to a protected object that contains a protected procedure that specifies either the Attach_Handler or Interrupt_Handler aspects, but does not specify the Interrupt_Priority aspect. !corrigendum E.2.1(7/4) @drepl @xbullets;> @dby @xbullet !corrigendum E.2.1(7.1/4) @drepl @xbullet @dby @xinbull @xinbull @xinbulls; or> @xinbull !ASIS No ASIS effect. !ACATS test No ACATS tests should be needed, all of these are mainly wording improvements. !appendix From: Randy Brukardt Written: Wednesday, March 06, 2019 6:45 PM Jeff's review includes: >E.2.1 (7/4) it shall not contain a library-level declaration of an access type >that designates a class-wide type, nor a type with a part that is of a task >type or {of a} protected type with entry_declarations; I've been removing those redundant "of a" when I can, I view it as just noise. Moreover, in this case, it would make a reading of "of a task type" or "of a protected type with entry_declarations" plausible (which is wrong!). If I was going to make any change here at all, I'd drop the "type" after "task", so it would read ("of a task or protected type with entry declarations". Ugh: after looking at the pre-change sentence, it's obvious that the "wrong" reading is actually the one intended. But then just adding "of a" doesn't seem to be enough -- it makes the intended wording plausible, but does little to make it clear. (The original wording had a comma which made it a lot clearer as to the intended grouping.) Since this wording is from the Corrigendum, we have to put it on the agenda in any case. **************************************************************** [From WG 9 review, issue #45, Tucker Taft] E.2.1(7.3/5) is the following: * of a type with a part that is of a protected type with entry_declarations; nor The use of "nor" in such a list is ungrammatical I believe. "Nor" is usable with "neither" but it is not appropriate for a list introduced by "it shall not contain ...". Should be simply "or" I believe. [Editor's reply:] The "nor" was added in the Corrigendum change, perhaps as a (failed) attempt to make this readable without additional bullets (which is what we gave up on at this time). I processed it as an Editorial Review on AI12-0320-1. ****************************************************************