CVS difference for ai12s/ai12-0213-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0213-1.txt

--- ai12s/ai12-0213-1.txt	2019/01/11 00:17:04	1.2
+++ ai12s/ai12-0213-1.txt	2019/01/11 01:27:49	1.3
@@ -1,6 +1,5 @@
-!standard 3.8(3)                                      19-01-10  AI12-0213-1/02
-!standard 3.8(7)
-!standard 3.8(8)
+!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
@@ -10,7 +9,7 @@
 !subject Unify record syntax
 !summary
 
-*** Missing.
+Allow an optional matching identifier on the end of record definitions.
 
 !problem
 
@@ -76,42 +75,48 @@
 
 !wording
 
-Replace 3.8(3)
+Replace 3.8(3) with:
 
 record_definition ::=
    record
       component_list
-   end record_terminator
+   end [/record_/identifier]
    | null record
 
-Add after 3.8(3)
+Add after 3.8(3):
 
-record_terminator ::= record [record_identifier]
+If a /record_/identifier appears at the end of the record_definition, it shall 
+repeat the defining_identifier of the enclosing full_type_declaration.
 
-Add after 3.8(7)
+Replace 3.8(28) with:
 
-The optional record_identifier within a given record_definition's
-record_termintor must match the name of its enclosing type_declaration.
-
-Replace 3.8(28)
-
     type Complex is
        record
           Re : Real := 0.0;
           Im : Real := 0.0;
        end record Complex;
 
-Replace 13.5.1(2)
+Replace 13.5.1(2) with:
 
 record_representation_clause ::=
    for first_subtype_local_name use
       record [mod_clause]
          {component_clause}
-      end record_representation_terminator;
+      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.
 
-Add after 13.5.1(2)
+!discussion
 
-record_representation_terminator ::= record [first_subtype_local_name]
+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
 
@@ -167,6 +172,152 @@
 
 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. :-)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent