CVS difference for ai12s/ai12-0213-1.txt
--- ai12s/ai12-0213-1.txt 2016/12/29 01:42:54 1.1
+++ ai12s/ai12-0213-1.txt 2019/01/11 00:17:04 1.2
@@ -1,4 +1,6 @@
-!standard 3.8(3) 16-12-28 AI12-0213-1/01
+!standard 3.8(3) 19-01-10 AI12-0213-1/02
+!standard 3.8(7)
+!standard 3.8(8)
!standard 13.5.1(2)
!class Amendment 16-12-28
!status work item 16-12-28
@@ -13,40 +15,33 @@
!problem
Ada's record_type_definition and record_representation_clause are unique to the
-language in that the way they are terminated is inconsistant with other
-declarations which have obvious names like package_declarations and
-subprogram_declarations. In fact, it is often the case that Ada programmers in
-the course of typing a record_type_definition accidently type "end identifier"
-out of force of habit instead of the correct "end record".
+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 identifier" and "end" syntax for record
-definitions so that their syntax matches subprogram_declarations and
-package_declarations. See the code segments below for an overview:
+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;
+ end record Rec_B;
for Rec_B use record
A at 0 range 0 .. 0;
B at 0 range 1 .. 1;
- end;
+ end record Rec_B;
-Or:
-
- type Rec_B is record
- A : Boolean;
- B : Boolean;
- end Rec_B;
-
- for Rec_B use record
- A at 0 range 0 .. 0;
- B at 0 range 1 .. 1;
- end Rec_B;
-
As an alternative to:
type Rec_B is record
@@ -63,73 +58,61 @@
Here is what the BNF would look like for the proposed changes:
- record_definition ::=
+ record_definition ::=
record
component_list
end record_terminator
| null record
- record_terminator ::= [defining_identifier]
- | [record]
+ record_terminator ::= record [record_identifier]
- record_representation_clause ::=
+ record_representation_clause ::=
for first_subtype_local_name use
record [mod_clause]
{component_clause}
end record_representation_terminator;
- record_representation_terminator ::= [first_subtype_local_name]
- | [record]
+ record_representation_terminator ::= record [first_subtype_local_name]
!wording
+
+Replace 3.8(3)
+
+record_definition ::=
+ record
+ component_list
+ end record_terminator
+ | null record
+
+Add after 3.8(3)
+
+record_terminator ::= record [record_identifier]
-** Missing!!!
+Add after 3.8(7)
-[Editor's note: Given that a record_definition does not have a name (that
-belongs to some outer construct, how to handle the necessary name checking
-is the only difficult part of such a proposal. (All existing constructs
-with a matching identifier have the defining_identifier as part of the
-construct and thus the rule is obvious.) A proposal without answering that
-question is clearly not completely thought out. Especially as a
-record_definition appears in an record_extension.]
-
-!discussion
-
-It is clear that the addition of the "end identifier" syntax would improve both
-readability for cases of multi-page records and writability due to progammer
-habit.
-
-However, allowing "end" alone does not necessarily improve readability. The
-reasoning behind its inclusion in this proposal is unification. Records
-defintions, which tend to be much smaller than subprogams and packages
-declarations, should be allowed to follow the same logic as these declaration
-constructs and share similar syntax rules.
-
-[Editor's rant: Existing "end identifier" rules apply only to program units.
-Other constructs (like statements and type declarations) repeat the kind of
-entity ["end case", "end loop", etc.] That's even true when the constructs
-have names -- "end loop Loop_Name;"!
-
-Additionally, we can't eliminate any existing syntax possibilities
-(acknowledged by the author), so there is no chance at making the language
-any more consistent. In addition, no other kind of type (other than those
-that double as program units) have any closing identifier, so argubly this
-change is making Ada *less* consistent.
-
-Moreover, every Ada style guide and tool enforces a requirement that the
-matching identifier is not omitted. It's only allowed because it was allowed
-historically; it is never intentionally used. Therefore, there is little
-reason to allow it here.
-
-I have sympathy for allowing the "end type_name", as most Ada programmers
-have written that at some time or other, but without a solution to the name
-matching problem (especially in record extensions) and with the problem of
-adding another style question for Ada programmers to argue over ["record"
-vs. "identifier"], plus allowing yet another case of bad style, I can't
-support this AI in its current form.
+The optional record_identifier within a given record_definition's
+record_termintor must match the name of its enclosing type_declaration.
-End Editor's Rant.]
+Replace 3.8(28)
+ type Complex is
+ record
+ Re : Real := 0.0;
+ Im : Real := 0.0;
+ end record Complex;
+
+Replace 13.5.1(2)
+
+record_representation_clause ::=
+ for first_subtype_local_name use
+ record [mod_clause]
+ {component_clause}
+ end record_representation_terminator;
+
+Add after 13.5.1(2)
+
+record_representation_terminator ::= record [first_subtype_local_name]
+
!ASIS
[Not sure. Does ASIS expose the matching name at the end of a
@@ -144,7 +127,7 @@
!appendix
From: Justin Squirek
-Sent: Wednesday, october 5, 2016 11:30 AM
+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
@@ -154,6 +137,36 @@
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.]
****************************************************************
Questions? Ask the ACAA Technical Agent