Minutes of Electronic ARG Meeting 62G
21 October 2020
Attendees: Steve Baird, John Barnes (starting at 10:54), Randy Brukardt, Arnaud Charlet, Jeff Cousins (starting at 10:38), Gary Dismukes, Claire Dross, Bob Duff, Brad Moore (starting at 10:40), Jean-Pierre Rosen, Ed Schonberg, Justin Squirek, Tucker Taft, Tullio Vardanega, Richard Wai.
Observers: None.
The meeting convened on Wednesday, 21 October 2020 at 10:32 hours EDT and adjourned at 12:52 hours EDT. The meeting was held using Google Meet. The meeting covered the entire agenda and finished early.
Steve welcomes everyone.
Justin says that he won’t be voting as he was unable to prepare due to his dog’s death over the weekend.
There were no comments on the minutes: Approve minutes: 12-0-0.
Following our approximately 6 week schedule, Randy had suggested Wednesday, December 2nd for our next meeting. That conflicts with some other meetings. We try a variety of other dates; Jean-Pierre has a tutorial on the 9th but that is the only conflict for that day. We settle on Wednesday, December 9th for our next meeting, same time and platform.
There are three unfinished action items (Steve Baird, AI12-0016-1; Tucker Taft: OpenMP Technical Report; Storage_Pools for formal access types). We did not spend any time talking about these.
The combined unfinished old action items and new action items from the meeting are shown below.
The minutes cover detailed review of Ada 2012 AIs (AI12s). The AI12s are presented in numeric order, which is not necessarily the order in which they were discussed. Votes are recorded as “for”-“against”-“abstentions”. For instance, a vote of 6-1-2 would have had six votes for, one vote against, and two abstentions.
If a paragraph number is identified as coming from the working Ada 202x AARM, the number refers to the text in draft 26 of the Ada 202x AARM. Paragraph numbers in other drafts may vary. Other paragraph numbers come from the final consolidated Ada 2012 AARM; again the paragraph numbers in the many drafts may vary.
This is an alternative for AI12-0384-2, which we approved instead.
No Action: 14-0-0.
Tucker explains the changes.
Brad comments that “Buffer_Overflowed” has a bad connotation, he suggests “Buffer_Truncated” instead. Ed says “At_Capacity”. Tucker suggests “Output_Truncated”. “Text_Truncated” is suggested. We agree on that.
Brad says that we need a comma after “is currently defined” in !problem, (1).
Also, (4) “There seems {to be} no particular advantage...”
In !proposal, (2), “the the”!
!discussion, 3rd real paragraph “you are willing” should be “one is willing”.
Gary notes that the first paragraph of !summary sounds awkward: “Add operations to associate with a Text_Buffer an adjustable level of indentation.” Put the “with a Text_Buffer” at the end of the sentence.
Approve AI with changes: 9-0-5. Jean-Pierre, Bob, Claire, Arnaud, Gary abstain.
Randy goes over all of the choices he made.
Steve had noted that the syntax for enumeration_literal_specification is a comma separated list, so adding an aspect_specification would be ambiguous. Randy proposes to remove this, as whatever fix is applied would make this not a simple change.
So the change to enumeration_literal_specification is removed, the discussion is changed to say NO, and the reason given is that the syntax would be ambiguous.
Brad has typos. The subject should be “allow” rather than “have”.
Steve would prefer that the subject start with “More” rather than “Most”. There are more noes than yeses in the AI. [The subject is talking about all declarations, not just those mentioned in the AI – Editor.]
Gary suggests dropping the ? from choice parameters.
In the chunk_specification paragraph, “unambigiously” should be spelled “unambiguously”.
Jeff asks if SPARK has any need for these currently. Arnaud says no, but he’s in favor of opening the door to future uses. Claire concurs. Tucker notes that no one needs to do anything to their implementation, as this is an option. If one has no aspects that can be specified on (say) a discriminant_specification, one doesn’t even need to add the syntax to their parser, as no legal program could tell the difference.
Approve AI with changes: 13-0-1. John abstains.
This is a weird hole in the aspect model. Tucker found that it would require not requiring matching between the partial view and the full view.
Jeff notes “specified as True” and “specified True”, should be consistent. He says that there are 9 “specified True” and 5 “specified as True” in the current RM. Make all of these “specified True”.
Approve AI with changes: 13-1-0. Bob is opposed, he’s opposed to the cosmetic part of this. John says he’s already changed his book.
Tucker reminds us of the problem: if the element is a record or array type, then Append is now ambiguous as containers now have aggregates.
Brad: last paragraph of the summary and recommendation are essentially the same, can we get rid of one of them? Doesn’t seem to be a problem (so long as they say the same thing).
Approve AI with changes: 13-0-0.
Steve asks Tucker if he wants to show the example of case statement being out of range if this is not checked. It seems important to show the problems that can be caused. Tucker will provide this example to the editor.
Steve asks if there was a reason for not using “statically compatible” here? Tucker thinks that everything is compatible with the first subtype. Randy looks at the rules in 4.9.1 and does not see anything like that. Rather, the rule is both stricter and more relaxed than the rule proposed here; there’s nothing like the first subtype/base type part for “static compatibility”, while “static compatibility” does allow different subtypes with the same static constraint. We won’t make any change.
Capitalize the “if” in the question. “{Consider}[In]” at the start.
Gary asks if this is an incompatibility with Ada 2012. It is, and that should be mentioned in the !discussion.
Approve AI with changes: 13-0-1. John abstains.
We want to allow local parameters to be passed to explicitly aliased parameters if it is blatantly obvious that an access to them cannot be buried in the result. If it could be hiding something that is build-in-place or some access type, there could be trouble (we’re removing an existing guarantee for the latter).
Tucker wants the rule to be simple, so it might need to be inverted.
“Aurhor” should be “Author”. “Aliasse”. “Bullet” should be plural in the !discussion. “these paragraph{s}”.
Approve intent: 7-1-6. Arnaud opposes, we are at the limit with the accessibility model; addressing this specific case isn’t going to add anything but complexity. Bob, Ed, Gary, Claire, Jeff, John abstain.
There is an alternative approach of leaving the accessibility level definitions alone and just changing some (accessibility-related) legality rules. One could be a bit more aggressive that way (the build-in-place issues go away). Some people would prefer that approach.
Randy and Tucker explain the changes.
Let’s remove (4) from this AI, as it needs more digestion. [It was placed into AI12-0404-1 after the meeting – Editor.]
Approve AI with changes: 14-0-0. (Without item (4)).
[Editor’s note: This AI number was assigned after the meeting.]
Should stable properties checks be restricted from out mode parameters? Tucker notes that one could require that something be stated about the stable properties of an out parameter.
Steve notes that would be essentially requiring the overriding rule to kick in for an out parameter. The idea is that stable properties are always well-defined.
Steve would prefer the simpler rule that one just doesn’t say anything about out parameters. He doesn’t like that a postcondition would be required and thus the absence of one would make the program illegal. Tucker doesn’t buy this argument, it only happens when one defines a stable property, that makes a requirement. If you are defining stable properties, you are saying that you want postconditions to define them.
We seem to agree that the stable property check does not apply to out parameters. The other part is less clear.
Straw vote: In favor of requiring that the property appear in the postcondition for each out parameter. Randy, Tucker, Richard, Tullio, Brad; No extra requirement: Steve, Ed, John, Claire, Jean-Pierre, Arnaud. Abstain: Gary, Bob, Jeff.
This is not quite a tie, but it is as close to one as we can get without it being a tie. We’d like to see how complex this added rule really would be to help make a decision.
Tucker had made a suggestion for in parameters, but he’s now convinced that it was a dubious idea, so we won’t consider that.
Steve will take an action item to write an AI for stable properties, and he will write a trial version of the requirement to write a postcondition for out parameters.