Version 1.4 of ai12s/ai12-0213-1.txt
!standard 3.8(3) 19-01-11 AI12-0213-1/03
!standard 3.8(28)
!standard 13.5.1(2)
!class Amendment 16-12-28
!status work item 16-12-28
!status received 16-10-06
!priority Very_Low
!difficulty Easy
!subject Unify record syntax
!summary
Allow an optional matching identifier on the end of record definitions.
!problem
Ada's record_type_definition and record_representation_clause are unique to the
language in that it is the only kind of type definition to feature an enclosed
list of components, and being that it is not a program unit or a named construct
such as a loop it was classically not considered relevant to allow an identfier
with its enclosing "end." However, many Ada users can attest to having records
with upwards of 15 or more components complete with comments and whitespace
leaving the enclosing "end record" to be below the page of start of the type
declaration - meaning some benefit would arise from being able to label the
"end record" with the type identifier.
!proposal
We propose introducing an "end record identifier" syntax for record
definitions (and thusly representation clauses) so that their syntax more
closely matches program units such as subprogram_declarations and
package_declarations. See the code segments below for an overview of the
proposed change:
type Rec_B is record
A : Boolean;
B : Boolean;
end record Rec_B;
for Rec_B use record
A at 0 range 0 .. 0;
B at 0 range 1 .. 1;
end record Rec_B;
As an alternative to:
type Rec_B is record
A : Boolean;
B : Boolean;
end record;
for Rec_B use record
A at 0 range 0 .. 0;
B at 0 range 1 .. 1;
end record;
Syntax
Here is what the BNF would look like for the proposed changes:
record_definition ::=
record
component_list
end record_terminator
| null record
record_terminator ::= record [record_identifier]
record_representation_clause ::=
for first_subtype_local_name use
record [mod_clause]
{component_clause}
end record_representation_terminator;
record_representation_terminator ::= record [first_subtype_local_name]
!wording
Replace 3.8(3) with:
record_definition ::=
record
component_list
end [/record_/identifier]
| null record
Add after 3.8(3):
If a /record_/identifier appears at the end of the record_definition, it shall
repeat the defining_identifier of the enclosing full_type_declaration.
Replace 3.8(28) with:
type Complex is
record
Re : Real := 0.0;
Im : Real := 0.0;
end record Complex;
Replace 13.5.1(2) with:
record_representation_clause ::=
for first_subtype_local_name use
record [mod_clause]
{component_clause}
end [local_name];
Add after 13.5.1(2):
If a local_name appears at the end of the record_representation_clause, it
shall repeat the first_subtype_local_name.
!discussion
We considered allowing "record" to be optional as well, so that one could
write "end Complex" for the example above. We rejected that because no one
wanted to allow "end" by itself in this context, and requiring either
"record" or an identifier would have added yet another way to terminate
a construct, reducing consistency further. This proposal is at least similar
to "end loop <id>".
!ASIS
[Not sure. Does ASIS expose the matching name at the end of a
construct?? - Editor.]
!ACATS test
An ACATS B-Test and C-Test are needed to check that the new capabilities are
supported.
!appendix
From: Justin Squirek
Sent: Wednesday, October 5, 2016 11:30 AM
I was considering amending my previous AI to be several (raise-when syntax
and a with-use clause), but after considering feedback I realized that these
would not blend well with the Ada language.
However, I do think proposing an AI on unifying record type declaration syntax
is worthwhile.
[This is version /01 of this AI, with a number of missing parts added. - Editor]
****************************************************************
From the minutes of the Lexington Meeting (October 2018):
Tucker suggests "end record <id>"; as an option, there is no interest in leaving
out the record. End by itself is disgusting.
Gary suggests that we would allow the name on end of the record representation
clause. Tucker argues against that, it doesn't declare anything. Others argue
that it could improve readability; it also would be consistent, otherwise you
would have to worry about the context of end record. We eventually agree that it
makes sense to allow it anywhere end record occurs.
The optional identifier has to match appropriately. Randy complains that a
record_definition (which is the construct with the end record) does not iteself
have an identifier. Rather, it is part of other constructs
(record_type_definition, record_extension) which themselves in turn are part of
a type_declaration, which is where the defining identifier comes from. So it is
not simple to describe the identifier that has to match. It should be possible
to describe this (perhaps by saying the "enclosing type_declaration"), we'll
leave it to the author to figure that out.
****************************************************************
From: Justin Squirek
Sent: Thursday, January 10, 2019 10:21 AM
Attached is my homework for AI12-0213-1-01, revised as per our discussions.
[This is version /02 - Editor.]
****************************************************************
From: Steve Baird
Sent: Thursday, January 10, 2019 4:25 PM
> The optional record_identifier within a given record_definition's
> record_termintor must match the name of its enclosing type_declaration.
Typo.
More significantly, I think we need an analogous rule for the
record_representation_terminator case.
And we should probably follow the example of existing similar wording in the RM.
We've got
If an entry_identifier appears at the end of an accept_statement, it
shall repeat the entry_direct_name.
If a designator appears at the end of a subprogram_body, it shall
repeat the defining_designator of the subprogram_specification.
If a task_identifier appears at the end of a task_definition or
task_body, it shall repeat the defining_identifier.
If a protected_identifier appears at the end of a
protected_definition or protected_body, it shall repeat the
defining_identifier.
If an identifier or parent_unit_name.identifier appears at the end of
a package_specification, then this sequence of lexical elements shall
repeat the defining_program_unit_name.
If an identifier or parent_unit_name.identifier appears at the end of
a package_body, then this sequence of lexical elements shall repeat
the defining_program_unit_name.
So I suggest adding two rules of the form "If a ... appears at the end of
a ..., it shall repeat the ...".
****************************************************************
From: Randy Brukardt
Sent: Thursday, January 10, 2019 7:08 PM
> Attached is my homework for AI12-0213-1-01, revised as per our
> discussions.
For the record changes:
Fixed the typo Steve mentioned.
---
The format of "Replace" and "Add" instructions should be:
Replace 3.8(3) with:
and
Add after 13.5.1(2):
adding "with :" and ":" respectively.
---
Minor technical issues:
You dropped !discussion. That's not an optional section, you need to either
say "(See Proposal.)" or write something. In this case, you could have said
something about making "record" optional as well, but the feeling was that
that is disgusting. And "end record <id>" is consistent with "end loop <id>",
so it's not completely out of left field.
A summary of "*** Missing" doesn't cut it either. There needs to be a
one-line explanation of the change. That's pretty easy here ("Allow an
optional matching identifier on the end of record definitions.")
Steve implied it in his note, but there is no matching rule for representation
clauses. And I agree with him about the form of the rule that's there -- always
steal existing wording if its possible.
Steve didn't mention in his note that the matching rule is considered a syntax
rule, and thus is placed as an English-language syntax rule. Thus these rules
need to be after 3.8(3) and 13.5.1(2), respectively. (Yes, there's no real
difference between an English language syntax rule and a legality rule, but
let's be consistent.)
record_terminator include "record_identifier". But this is undefined syntax.
If you meant that to be an italicized prefix, you need to write that somehow.
Lately, we've been using /record_/identifier to show the italics. Otherwise,
both reviewers and the editor will be confused. But we don't really need the
/record_/ part anyway, the wording is fine without it. OTOH, it's consistent
with task and protected bodies (but not subprogram or package bodies), so I
left it as there is already no consistency to follow.
The existing constructs do not separate out the terminator production, they
just include the identifier in the main syntax. That fits better with the
wording that Steve suggested. So we should drop the record_terminator and
record_representation_terminator productions.
That gives us rules of:
If an identifier appears at the end of the record_definition, it shall repeat
the defining_identifier of the enclosing full_type_declaration.
[And yes, I verified in the syntax that every record_definition ultimately
has to be part of a full_type_declaration.]
And
If an identifier appears at the end of the record_definition, it shall repeat
the first_subtype_local_name of the enclosing record_representation_clause.
I created an update to the AI (version /03) that incorporates all of these
changes. It will be dated tomorrow as there is a policy of not posting more
than one version per day (but available with the agenda tonight).
P.S. Justin, don't get too discouraged by this level of editing. This AI is
was originally about increasing the consistency of the language, and while
it doesn't quite accomplish that, it's valuable to at least keep the
presentation consistent with the existing language. It's easier when you're
working with an entirely new concept, because you can make up a lot of it as
you go. (Of course, even then, you'll get bashed by the comma police and
Mr. Hyphen, not to mention Steve telling us that we have to add "immediately"
or pointing out some generic problem. Maybe you have a right to get
discouraged. :-)
****************************************************************
From: Randy Brukardt
Sent: Thursday, January 10, 2019 7:26 PM
> If an identifier appears at the end of the record_definition,
local_name---^ ^
record_representation_clause-----------------^
> it shall repeat the first_subtype_local_name of the enclosing
> record_representation_clause.
The part after "of" is unnecessary in this rule, since this is occurring in
a single construct. Look at the similar rule for task bodies, for instance.
At least I caught these before posting. And it demonstrates that getting this
stuff right is hard, especially when you are in a hurry 'cause you
underestimated the work remaining. :-)
****************************************************************
From: Gary Dismukes
Sent: Thursday, January 10, 2019 7:33 PM
> More significantly, I think we need an analogous rule for the
> record_representation_terminator case.
Agreed.
>
> And we should probably follow the example of existing similar wording
> in the RM.
>
> We've got
> If an entry_identifier appears at the end of an accept_statement, it
> shall repeat the entry_direct_name.
>
> ...
So it should be something like:
If a \record_\identifier appears at the end of a record_definition, it shall
repeat the defining_identifier of the enclosing full_type_declaration.
(I think we want to use full_type_declaration rather than type_declaration,
because the former has the defining_identifier.)
By the way, I don't see the benefit of adding two new nonterminals in this
proposal (record_terminator and record_representation_terminator).
Why not just have:
record_definition ::=
record
component_list
end record [\record_\identifier]
| null record
and similarly for the record_representation_clause case?
****************************************************************
From: Steve Baird
Sent: Thursday, January 10, 2019 7:53 PM
> Why not just have:
>
> record_definition ::=
> record
> component_list
> end record [\record_\identifier]
> | null record
>
> and similarly for the record_representation_clause case?
Agreed. That's how it is handled in all the other cases (if you search the
syntax summary page for "end [", there are 10 such occurrences).
****************************************************************
From: Randy Brukardt
Sent: Thursday, January 10, 2019 8:27 PM
You guys are too late, see my message sent 7:09 PM where I pointed that out
and fixed it.
****************************************************************
Questions? Ask the ACAA Technical Agent