Version 1.9 of ai12s/ai12-0347-1.txt

Unformatted version of ai12s/ai12-0347-1.txt version 1.9
Other versions for file ai12s/ai12-0347-1.txt

!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 WG9 Approved 22-06-22
!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
(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)
Insert after the paragraph:
function Image (Date : Time; Include_Time_Fraction : Boolean := False; Time_Zone : Time_Zones.Time_Offset := 0) return String;
the new paragraph:
function Local_Image (Date : Time; Include_Time_Fraction : Boolean := False) return String is (Image (Date, Include_Time_Fraction, Time_Zones.Local_Time_Offset (Date)));
!corrigendum 12.6(15)
Replace the paragraph:
17 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 _instantiation.
by:
17 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.
!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)
Replace the paragraph:
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; -- 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;
by:
with Tapes, Name_Server; package body Tape_Driver is type New_Tape is new Tapes.Tape with ... overriding 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;
!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."

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

Questions? Ask the ACAA Technical Agent