!standard 9.6.1(35.1/5) 20-02-19 AI12-0347-1/04 !standard 12.6(15) !standard C.6(19.1/5) !standard E.4.2(5) !class presentation 19-10-28 !status Amendment 1-2012 20-01-29 !status ARG Approved 13-0-1 20-03-11 !status work item 19-10-28 !status received 19-10-28 !priority Low !difficulty Easy !qualifier Omission !subject Presentation issues !summary [Editor's note: These changes are included in the current draft of the Standard, even though they are not yet approved.] (1) Replace the fragment "_instantiation" with "generic_instantation". (2) Add a specification for Rewind. (3) Add "Time_Zones." in front of Local_Time_Offset. (4) Reword C.6(19.1/5). !question (1) There seems to be a typo in 12.6(15): "...directly visible at the place of the _instantiation." (2) The example in E.4.2 is illegal; the occurrence of the Copy body freezes type New_Tape and thus the later overriding declaration of Rewind is illegal. (3) There is no use clause for Time_Zones in Ada.Calendar.Formatting, so all of the references to things defined in it need the prefix "Time_Zones.". For instance, all of the parameters of type Time_Offset have this prefix. But the default parameter Local_Time_Offset is missing it. (4) We don't usually use a phrase like "shall be implemented" in Dynamic Semantics; that sort of wording is usually used in Implementation Requirements. !response (1) This is not a typo; "_instantiation" is in the syntax font. This appears to be a shorthand for "generic_instantiation". But the full term isn't enough longer to justify the shorthand (and the confusion and queries like this one that it causes), so we replace the shorthand by the full term. (2) This is correct, a separate specification is required for Rewind. We add overriding indicators as well to clarify what is going on. (3) Yes, the call should be written Time_Zones.Local_Time_Offset. (4) We want to leave this wording in Dynamic Semantics, so it is best to reword the paragraph. !wording (1) Modify 12.6(15): A default_name denotes an entity that is visible or directly visible at the place of the generic_declaration; a box used as a default is equivalent to a name that denotes an entity that is directly visible at the place of the {generic_instantiation}[_instantiation]. [Editor's note: There are three similar occurrences in AARM notes in Clause 12; we also change those.] (2) Modify E.4.2(5): with Tapes, Name_Server; package body Tape_Driver is type New_Tape is new Tapes.Tape with ... {overrriding procedure Rewind (T : access New_Tape); overriding} procedure Copy (From, To : access New_Tape; Num_Recs: in Natural) is begin . . . end Copy; procedure Rewind (T : access New_Tape) is begin . . . end Rewind; -- Objects remotely accessible through use -- of Name_Server operations Tape1, Tape2 : aliased New_Tape; begin Name_Server.Register ("NINE-TRACK", Tape1'Access); Name_Server.Register ("SEVEN-TRACK", Tape2'Access); end Tape_Driver; [Editor's note: this is the minimum change. A real program probably would give all of the overriding specifications. But a real program probably wouldn't have a type extension in a body, either.] (3) Modify 9.6.1(35.1/5): function Local_Image (Date : Time; Include_Time_Fraction : Boolean := False) return String is (Image (Date, Include_Time_Fraction, {Time_Zones.}Local_Time_Offset (Date))); (4) Modify C.6(19.1/5): All reads of or writes to any nonatomic subcomponent of an atomic object {are performed}[shall be implemented] by reading and/or writing all of the nearest enclosing atomic object. !corrigendum 9.6.1(35/2) @dinsa @xcode< @b Image (Date : Time; Include_Time_Fraction : Boolean := False; Time_Zone : Time_Zones.Time_Offset := 0) @b String;> @dinst @xcode< @b Local_Image (Date : Time; Include_Time_Fraction : Boolean := False) @b String @b (Image (Date, Include_Time_Fraction, Time_Zones.Local_Time_Offset (Date)));> !corrigendum 12.6(15) @drepl @xindent<@s9<17 A @fa denotes an entity that is visible or directly visible at the place of the @fa; a box used as a default is equivalent to a name that denotes an entity that is directly visible at the place of the @fa<_instantiation>.>> @dby @xindent<@s9<17 A @fa denotes an entity that is visible or directly visible at the place of the @fa; a box used as a default is equivalent to a name that denotes an entity that is directly visible at the place of the @fa.>> !corrigendum C.6(19) !comment Need to match the form of AI12-0128-1. @dinsa If an actual parameter is atomic or volatile, and the corresponding formal parameter is not, then the parameter is passed by copy. @dinst All reads of or writes to any nonatomic subcomponent of an atomic object are performed by reading and/or writing all of the nearest enclosing atomic object. !corrigendum E.4.2(5) @drepl @xcode<@b Tapes, Name_Server; @b Tape_Driver @b @b New_Tape @b Tapes.Tape @b ... @b Copy (From, To : @b New_Tape; Num_Recs: @b Natural) @b @b . . . @b Copy; @b Rewind (T : @b New_Tape) @b @b . . . @b Rewind; @ft<@i<-- Objects remotely accessible through use>> @ft<@i<-- of Name_Server operations>> Tape1, Tape2 : @b New_Tape; @b Name_Server.Register ("NINE-TRACK", Tape1'Access); Name_Server.Register ("SEVEN-TRACK", Tape2'Access); @b Tape_Driver;> @dby @xcode<@b Tapes, Name_Server; @b Tape_Driver @b @b New_Tape @b Tapes.Tape @b ... @b @b Rewind (T : @b New_Tape); @b @b Copy (From, To : @b New_Tape; Num_Recs: @b Natural) @b @b . . . @b Copy; @b Rewind (T : @b New_Tape) @b @b . . . @b Rewind; @ft<@i<-- Objects remotely accessible through use>> @ft<@i<-- of Name_Server operations>> Tape1, Tape2 : @b New_Tape; @b Name_Server.Register ("NINE-TRACK", Tape1'Access); Name_Server.Register ("SEVEN-TRACK", Tape2'Access); @b Tape_Driver;> !ASIS No ASIS effect. !ACATS test No ACATS tests needed for presentation issues. !appendix From: Pascal Pignard Sent: Monday, October 28, 2019 1:20 PM [From private mail.] I'm reading the AARM 202x draft 22 (text version). I've found up to now 2 typos: . Introduction - Using this version of the Ada Reference Manual - §77.5 "Some versions also use color to indicate the version of the change.Where paragraphs are inserted," -> space missing "change.Where" . Chapter 12, leading underscore "_instantiation", 4 times: AA-12.TXT:651: they are, of course, observed in the _instantiation in order to AA-12.TXT:653: _instantiation. AA-12.TXT:819: _instantiation need not look at the private part of the generic in AA-12.TXT:2706: directly visible at the place of the _instantiation. **************************************************************** From: Randy Brukardt Sent: Monday, October 28, 2019 11:26 PM > I'm reading the AARM 202x draft 22 (text version). Fonts are significant in the AARM, so one can't really use the text version alone when reading/reviewing the AARM. It's provided because some people want it, but it is better to use the HTML (which has links) or PDF (which is a bit easier to read) versions. > I've found up to now 2 typos: > > . Introduction - Using this version of the Ada Reference Manual - > §77.5 "Some versions also use color to indicate the version of the > change.Where paragraphs are inserted," -> space missing "change.Where" Interesting; that's been the case since Ada 2005. Easy to fix, though. > . Chapter 12, leading underscore "_instantiation", 4 times: > AA-12.TXT:651: they are, of course, observed in > the _instantiation in order to > AA-12.TXT:653: _instantiation. > AA-12.TXT:819: _instantiation need not look at the > private part of the generic in > AA-12.TXT:2706: directly visible at the place of the > _instantiation. These are all syntax terms; the leading underscore is not a mistake. It's rather a shorthand for "generic_instanstation". If you look at a version that shows the fonts, this text is in the syntax font, not the regular text font. I suspect this is text from a very early version of Ada 9x when there were multiple syntax terms for an instance ("generic_package_instantiation", "generic_procedure_instantation", etc.). Writing all of those out would have been ugly to read, so they just wrote the common part. It's done in other places in the AARM notes (never normative text). It doesn't seem necessary anymore. [Editor's note: The theory given above for the use of these shorthands is not true, even version 1.2 of Ada 9x uses "generic_instantiation". It's not at all obvious what the reason for this text was, 7 characters hardly seems worth omitting when that necessarily makes things less clear.] **************************************************************** From: Pascal Pignard Sent: Sunday, November 24, 2019 5:13 AM [From private mail.] Annex "E.4.2 Example of Use of a Remote Access-to-Class-Wide Type", I've found: 5 with Tapes, Name_Server; package body Tape_Driver is type New_Tape is new Tapes.Tape with ... procedure Copy (From, To : access New_Tape; Num_Recs: in Natural) is begin . . . end Copy; procedure Rewind (T : access New_Tape) is begin . . . end Rewind; Shouldn't Copy and Rewind specifications added before bodies? Like: type New_Tape is new Tapes.Tape with ... procedure Copy (From, To : access New_Tape; Num_Recs: in Natural); procedure Rewind (T : access New_Tape); procedure Copy (From, To : access New_Tape; Num_Recs: in Natural) is begin . . . end Copy; procedure Rewind (T : access New_Tape) is begin . . . end Rewind; **************************************************************** From: Randy Brukardt Sent: Sunday, November 24, 2019 6:37 PM That's not necessary. The body of a subprogram can act as a specification, including for overriding an inherited subprogram. It *is* necessary to override both before freezing the type, and a body freezes everything declared ahead of it, so you can override exactly one routine with a body. Thus, *one* of these routines needs a specification, but not both. Probably if we were to update these, we should also add overriding indicators on the routines to make it clearer what's going on. **************************************************************** From: Pascal Pignard Sent: Monday, November 25, 2019 2:59 PM Exactly, I get the following error with GNAT: aarm_202x_chae.adb:59:17: overriding of "Rewind" is too late aarm_202x_chae.adb:59:17: spec should appear immediately after the type Thus I agree only Rewind specification is necessary but I thought that adding both was more compliant with Ada style ;-) **************************************************************** From: Arnaud Charlet Sent: Friday, January 31, 2020 8:16 AM In implementing AI12-0336 Meaning of Time_Offset in GNAT, I found that we need the following small change: Replace function Local_Image (Date : Time; Include_Time_Fraction : Boolean := False) return String is (Image (Date, Include_Time_Fraction, Local_Time_Offset (Date))); with: function Local_Image (Date : Time; Include_Time_Fraction : Boolean := False) return String is (Image (Date, Include_Time_Fraction, Time_Zones.Local_Time_Offset (Date))); In other words, we have no 'use' clause on Time_Zones and Local_Time_Offset cannot be resolved. **************************************************************** From: Randy Brukardt Sent: Friday, January 31, 2020 7:29 PM Makes sense, since all of the parameter types in the package use "Time_Zones.Time_Offset". I'll put this into the "presentation" AI (the current one is AI12-0347-1), since it doesn't involve any semantic change. [The "presentation" AI gathers a bunch of changes that don't change semantics and should be non-controversial into a single AI -- that cuts admin overhead and hopefully meeting time. I also apply the changes in it immediately to the draft RM without waiting for ARG approval, so we don't have to wait to get rid of silly mistakes.] **************************************************************** From: Arnaud Charlet Sent: Saturday, February 1, 2020 2:50 AM > Makes sense, since all of the parameter types in the package use > "Time_Zones.Time_Offset". Right. > I'll put this into the "presentation" AI (the current one is > AI12-0347-1), since it doesn't involve any semantic change. [The > "presentation" AI gathers a bunch of changes that don't change > semantics and should be non-controversial into a single AI -- that > cuts admin overhead and hopefully meeting time. I also apply the > changes in it immediately to the draft RM without waiting for ARG > approval, so we don't have to wait to get rid of silly mistakes.] Makes sense and certainly works for me, I agree that we want to keep the overhead of such change minimal. **************************************************************** From: Tucker Taft Sent: Thursday, February 13, 2020 7:58 PM [From private mail.] I suspect we already talked about this, but I see in the most recent online version of the RM, it still says the following, in C.6(19.1/5): "All reads of or writes to any nonatomic subcomponent of an atomic object shall be implemented by reading and/or writing all of the nearest enclosing atomic object." That "shall be implemented by ..." should be phrased as a statement of fact rather than a requirement, since it appears in the "Dynamic Semantics" section. Probably should be: "All reads of or writes to any nonatomic subcomponent of an atomic object are implemented by reading and/or writing all of the nearest enclosing atomic object." Sorry if this has already been discussed... **************************************************************** From: Randy Brukardt Sent: Friday, February 14, 2020 2:15 PM [From private mail, after a bunch of unimportant discussion] I think we need to talk about it, for no other reason than that seems weird as a Dynamic Semantics rule. Either "shall be implemented" or "is implemented" seems like an Implementation Requirement, rather than something about Dynamic Semantics. We don't usually talk about implementation in Dynamic Semantics, that's left to the implementor. Ergo, one option is to leave "shall" and move the rule to Implementation Requirements. Or alternatively, leave it where it is and use "is". I don't think we necessarily ought to choose that (alone). (And I'd need to research if we put it into Dynamic Semantics for a reason or just by fiat.) **************************************************************** From: Tucker Taft Sent: Saturday, February 15, 2020 2:15 PM [From private mail.] I agree having the word "implemented" there is awkward. Better would be perhaps: "All reads of or writes to any nonatomic subcomponent of an atomic object are performed by reading and/or writing all of the nearest enclosing atomic object." or, go singular with: "A read of or write to a nonatomic subcomponent of an atomic object reads and/or writes all of the nearest enclosing atomic object." ****************************************************************