Minutes of Electronic ARG Meeting 62L

9 September 2021

Attendees: Raphael Amiard (leaves 12:08 EDT), Steve Baird, John Barnes (leaves 12:28 EDT), Randy Brukardt, Arnaud Charlet (arrives 12:14 EDT), Jeff Cousins, Gary Dismukes, Claire Dross, Bob Duff, Edward (Joey) Fish, Brad Moore, Ed Schonberg, Justin Squirek, Tucker Taft, Tullio Vardanega, Richard Wai.

Observers: None.

Meeting Summary

The meeting convened on Thursday, 9 September 2021 at 10:33 hours EDT and adjourned at 12:32 hours EDT. The meeting was held using Google Meet. The meeting covered the entire agenda.

Detailed Minutes

Welcome

Steve welcomes everyone.

Apologies

Jean-Pierre Rosen sent apologies. Arnaud Charlet will be coming very late (he has a parent-teacher conference that conflicts).

Previous Meeting Minutes

There were no additional comments on the minutes; previous comments have been applied to the posted version. Approve minutes: 15-0-0.

Date and Venue of the Next Meeting

Randy has proposed November 18th, 10:30 AM EST for our next (electronic) meeting. No one objects to this date and time.

Randy asks if we are planning to have a physical meeting at Ada Europe. Steve asks if Ada Europe will be held. Tullio says that it is planned as a hybrid event. The physical meeting will be in Ghent, Belgium, June 13-17. ARG would be June 17-19, 2022. We’ll tentatively plan for those dates, and revisit closer to the meeting.

Tucker says that there will be a HILT workshop in Ann Arbor MI next fall. That could also be a possible ARG physical meeting window.

Unfinished Action Items

There are two unfinished action items (Steve Baird, AI12-0016-1; Tucker Taft: OpenMP Technical Report). We did not discuss these.

Current Action Items

The combined unfinished old action items and new action items from the meeting are shown below.

Everyone:
Steve Baird:
Randy Brukardt:
Tucker Taft:
Richard Wai:

General

Steve notes that this meeting will be unusual as we do not intend to discuss any technical topics. Randy asks to mention the intent that (major) topic discussion be limited to 20 minutes each, in order to ensure that we cover all of the topics. No one objects to this limit.

Contingency planning for changes to Ada 202x draft required by ISO

Randy had sent out a lengthy discussion of these issues to the ARG list. In a nutshell, the SC 22 people told Pat that they thought it was unlikely that the submitted draft Standard would be accepted by ISO because of various violations of the drafting Standard. We have argued that we’ve simply copied the form of the existing Standard; changing the draft (especially changing the subclause numbering) would make a new Standard unnecessarily hard to use for users; SC 22 does not expect that to fly. Several people concur with John’s reaction to this (the strongest ISO-approved swear word).

Randy posed a series of questions in the agenda in order to have a plan in case ISO does reject the draft.

What do we send to ISO? PDF and Doc. It has been suggested to only send the PDF. Randy says that he sent Pat both the PDF and Doc, but he has no idea what Pat forwarded. He also notes that the Doc file is created by loading and resaving the .RTF created by our tools; we do not work directly on that at any point.

Randy notes that the tools can handle reordering the subclauses. For the tools, a document is defined by a master file, which (among other things) defines the collating order of the original source files. It also can select options, including those that differ between ISO versions and RM versions. We already have a number of such options, such as text that only appears in ISO documents or only in the RM. Adding more is not a change in philosophy for the tools. The ISO version need not look anything like the RM version.

Tucker suggests that we allow the ISO draft to be different from the RM. Of course, if we think that some current ISO rule is an improvement (as with the note format), then we can change the RM as well.

Joey suggests that we add an Annex to the ISO version that gives the correspondence between the 2022 edition and the 2012 edition’s clause numbers.

As far as the note format goes, we agree that we should use the current ISO rule rather than the weird compromise that was used in Ada 95. Randy also wants to know if we should do this now, regardless of whether ISO requests a change. He notes that he will have to regenerate the documents at least once more for Ada 2022, at least to replace all of the Ada 202x with Ada 2022, and most likely to create a Springer version for Ada-Europe. So it would not be extra work to make the change in the final Ada 2022 documents (especially as the needed commands were implemented some time before Ada 2012 was submitted).

It is agreed that we should make this change the next time the RM is regenerated.

Randy asks which font we should use for syntax, assuming that we can only use two fonts (one for examples and one for body text). Tucker thinks it should be the same as the body text. No one objects.

We briefly discuss the fact that the RM has terms that mean different things if they are formatted as a syntax term or formatted as text. “Body” is an example, the syntax term is a number of syntactic bodies, while the textual term includes both the items included in the syntax and some additional entities (some things that can act as declarations or completions depending on context). In order to make things clearer, we should use different terms for these things (one should be changed, Randy had suggested somewhat tongue-in-check that the syntax term be changed to “some_body”). Randy notes that these sorts of conflicts can be confusing, and most likely violate accessibility rules [not our accessibility rules – Editor] for the visually impaired. [In the US, this would be a violation of the ADA law, so the Ada RM violates ADA. Humm. - Editor] We decide that we should immediately open a project for this purpose, but it will be applied post-Ada 2022.

As far as definitions go, Tucker noted that the Vulnerabilities Standard uses the Ada 95 “definitions are in italics” idiom, so perhaps we won’t have to do anything here. If we do, he wonders if we could repurpose the Glossary for this use. Randy notes that there are 6 pages of rules about the form of definitions, and moreover the Glossary was created for human understandability rather the definitional precision. So it’s not clear whether it would help.

We agree that we will develop definitions only if absolutely necessary, and they would appear only in the ISO version in that case.

To summarize the questions and answers:

(1) If ISO requires renumbering the clauses and subclauses of the document, this should be handled
[B] by mechanically converting the RM to the layout/formats required by ISO.

(2) The note numbers should be
[A] be changed the next time the RM is generated to meet the drafting standard (before the final Ada 2022 versions).

(3) If ISO requires the elimination of the serifed font
[B] the syntax and body text will become sans-serif.

(4) Should conflicts between syntax non-terminals and defined terms be eliminated
[B] Post Ada 2022. If ISO requests font changes (or does it on their own), the Standard will be misleading in a few cases (such as “body”).

(5) If ISO requires the creation of hundreds of separate definitions
[B] They should be included only in the ISO Standard, not in the RM.

Steve asks if anyone objects to these choices. No one does.

Raphael asks to defer the next topic as he needs to leave in an hour and would like to discuss the other agenda topics.

Processing language changes and clarifications

Tucker says that this was discussed at AdaCore yesterday, and the feeling was that the existing process works pretty well for language fixes, there’s no reason to change it.

We should name the new AIs “AI22s”. Randy will create a new set of AIs and update the tools to process them.

The hold AIs should be fed into the enhancement process, whatever it is, and for now, nothing should be done with them (until that enhancement process is defined). Unless a hold AI is about a fix, in which case they should be promoted to AI22s.

We will drop the !ASIS section from AI22s. Otherwise, the format will stay the same (pending other developments). Tucker notes that we may eventually want to reconcile their format with whatever is decided for enhancement processing

The editor and chair are directed to start processing the backlog of issues, which means created new AIs out of raised topics.

Steve asks if anyone objects to these decisions. No one opposes.

Joey asks how we determine whether something is an enhancement. He gave an example of a quantum computer not having traditional bits; is eliminating dependence on them an enhancement or fix? This discussion gets far off track, but we agree that support for quantum computers would probably be an enhancement.

Channels for user-community input to the ARG and for ARG work

[Editor’s Note: These two topics were combined and discussed for a double time allotment.]

Raphael says that Ada-Comment is inadequate. There is no user-accessible archive (actually, there is, but it is hard to use). [Editor's take: Perhaps it would be better to say that there is no HTTP accessible archive. But almost all Ada-Comment mail is filed into AIs and the AIs are web accessible – including searchable from both Google and the dedicated search tool on Ada-Auth.org].

Tucker suggests we define requirements for an input mechanism. Richard suggests that we have a tracker for issues, so that there is a feedback mechanism. Raphael says that they tried to use Github bug tracker for that; but that it proved to not be the right level. AdaCore intends to retire that system (at least for public input) if the ARG gets this right. Claire notes that we want to ask for problems not for solutions – people don’t necessarily know the language enough to provide good solutions. Steve agrees; Randy notes that we already try to encourage this. [Editor's note: All of the public requests from the ARG since about 2001 have included such a requirement.]

The opinion is raised that sometimes, feature suggestions are needed as well.

Richard suggests keeping those things separate (problems vs. feature suggestions).

Github’s bug tracker is rather hard to use for this purpose.

Richard suggests that we look at the Illumos bug tracker and Topicbox.

We definitely want to use something existing, not something that we construct.

Google groups is suggested. Several people don’t think that it has enough browsability.

The scheme needs to be web-based, have an ability to assign tags, and searchable.

Tullio notes that an open forum needs to be moderated. Otherwise, we’ll also have a lot of threads about the best hookup sites and the dangers of vaccinations.

Raphael wonders who should be the moderator(s)?

Randy notes that we currently have a procedure for determining what gets on the ARG agenda. Tucker notes that that is done by two people; we would like a more open mechanism. Raphael notes that it should be a more open group; it’s not just the ARG that would be interested in Ada enhancements.

Someone suggests that ARG membership is not necessarily needed for group moderators.

Someone asks if there is a definition of the format of an AI. Randy notes that it is different for each classification; he inherited this (probably all the way from Ada 83 and John Goodenough). Perhaps that should be changed.

Tucker suggests setting up a subgroup for determining the format of documents. [No more was said about this, in particular, no action item was assigned. Moreover, the Editor needs to know the format to use in a few weeks, not at typical ARG speed. There already is an internal formatting document for the ARG, it should be distributed to the ARG again, and probably posted somewhere.]

Tucker notes that this is a layer cake, which ends with an AI (for the ARG). The first layer is a free-form forum. Perhaps a middle layer for proposals (rough solutions) and discussions on them. [This roughly corresponds to the roles of Ada-Comment (the forum) and the ARG mailing list (discussing rough solutions – Editor.]

Richard notes that we have a very strong backbone for Ada; we need to have a way to keep from getting off the rails for Ada. It is thought that would be the bar for promoting things to the ARG; there’s no problem allowing proposals for dubious things on the forum. We already allow that on Ada-Comment. Raphael notes that AdaCore’s system got very few dubious suggestions (and most of them came from a single person). [That would be true on Ada-Comment as well, most of the suggestions have been reasonable – Editor.]

Raphael says moderation should be for “social” rules, not technical ones. Rust has a “code of conduct” for this purpose.

Ed notes that the ARG works at a geological pace; how to give more timely feedback to users?

We need a process that can be explained to the users; it can’t be too flexible.

Tucker suggests that we explain why we didn’t go forward with some suggestion from the user community. Randy notes that we don’t require that now (for Ada-Comment suggestions). Raphael thinks that doing so would require a lot of effort better spent elsewhere. There is a lot of reasons we might not want to do something, including other things being judged more important, no vendor support, compatibility issues, not enough energy for the project, etc. And rejections come from many levels, from the "triage" step, to various formal steps (no volunteer to write a proposal, rough proposal rejected, wording rejected, AI rejected by WG 9). [One worries that some proposers could take rejections personally - Editor.]

Some people are scared by the idea of a “code of conduct” and would like to avoid that (developing it could take a lot of effort).

Working group: Richard, Joey, Tucker, Raphael. (Steve and Randy will monitor the groups work.) Richard gets an action item to organize an initial meeting of the group. He will send an announcement to the ARG list when he is ready; anyone can join, not just the people listed above.

We will need some sort of login. Use Google account? We hope that will be included in whatever solution we chose. It seems unlikely that we would build something for this, at most it would be a collection of existing facilities tied together. While it would be great to build an all-Ada solution, it’s hard to see where the energy would come to keep it going for the long haul.

ACATS Testing for Ada 2022

Should the ARG assign tests? Tucker suggests ARG creating objectives.

Randy suggests not writing objectives specifically, just creating tests for objectives. He notes that he has already created objectives for parts of Ada 2022, and will have to continue that in order that the existing detailed objective documents aren’t out of date.

He would like to see C-Tests, from the ARG as these require real usage scenarios and those require a lot of imagination to come up with. B-Tests don’t require the same level of usage scenario (it’s only necessary that the underlying features are likely to be used; the assumption is that any error that can occur eventually will occur).

Randy feels that it would be a better use of our resources if generating B-tests is left to him and other folks write C-tests; nobody disagrees.

Claire suggests posting a list of possible choices for assignments; and letting people chose what they want. Steve and Randy will set up something (probably a Google doc), giving a set of possible assignments, and a way to select one.

Gary notes that we need a shaming mechanism to ensure that tests actually get created. Only three tests got created the last time. Tucker notes that it is homework, and no one has any homework right now. There should be at least one test completed before the next meeting. [Maybe laggards have to buy all of the beer at the June meeting? It's Belgium, that's likely to be a lot of beer. ;-) - Editor.]

Are there any features that need special emphasis?

Joey said that he would like to work on Annex D tests. Randy notes that there are no Annex D C-Tests for anything added since Ada 95; he doesn’t have the usage cases needed to properly test those features. [Also, he hasn’t done any B-Tests, either, as C-Tests are much more important.]

Richard notes that testing Annex B is important. Randy notes that Annex A and B are core and thus will be covered in the suggested test areas.

New aggregate features are noted as being likely to be heavily used.