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

--- ai12s/ai12-0005-1.txt	2013/12/12 04:24:25	1.10
+++ ai12s/ai12-0005-1.txt	2014/02/06 02:25:24	1.11
@@ -143,11 +143,114 @@
 Sent: Wednesday, December 11, 2013   9:43 PM
 
 There is an unhyphenated "classwide" in 6.8(5.b/3). "...and the static
-classwide accessibility check cannot fail..."
+classwide accessibility check cannot fail..." There are also
+occurrences in 3.7.2(3.b/3) [two occurrences], 7.6.1(9.b/3),
+7.6.1(24.ee/3), and E.2.2(20.j/3).
 
 ***************************************************************
 
-Editor's note (December 11, 2013): All of the items above this
+From: Adam Beneschan
+Sent: Tuesday, February  4, 2014  10:03 AM
+
+Is there a reason why the Shift_*** and Rotate_*** subprograms defined in
+Interfaces (in B.2) aren't listed in Q.3, or was this an oversight?
+They also don't have their own Index entries.  (By contrast, the subprograms
+in Interfaces.C, defined in B.3, are in both places.)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February  5, 2014  6:51 PM
+
+I can't find any documentation of the reason, but I think I omitted them
+because the contents of package Interfaces is formally implementation-defined.
+(See B.2(1) and especially AARM B.2(1.a)).
+
+As further evidence of this reasoning, note the difference between the handling
+of these packages for restriction "No_Implementation_Identifiers". In
+particular, all identifiers in Interfaces are considered implementation-defined
+(13.12.1(2.11/3) and 13.12.1(2.15/3)), while only added identifiers in
+Interfaces.C are considered implementation-defined (13.12.1(2.2/3) and
+13.12.1(2.6/3)).
+
+As such, they're not "language-defined" identifiers and thus they don't belong
+in Annex Q. Note that you don't find Long_Integer or Short_Integer in Annex Q,
+either. (Given the special handling for Long_Integer and Long_Float for the
+purposes of restriction No_Implementation_Identifiers, perhaps they ought to
+be there.)
+
+They probably ought to be in the main index, but I probably forgot about them
+simply because the usual command does all of that automatically (it adds a
+subprogram to the Annex Q and main indexes with a single operation). Since I'm
+not using the usual command, I ended up not using any command. I'll fix that
+for future versions.
+
+P.S. Note that the indexes are non-normative, so these are treated like
+questions on the AARM; so this thread will be filed in AI12-0005-1 with other
+AARM questions.
+
+***************************************************************
+
+From: Adam Beneschan
+Sent: Wednesday, February  5, 2014  7:21 PM
+
+> I can't find any documentation of the reason, but I think I omitted 
+> them because the contents of package Interfaces is formally 
+> implementation-defined. (See B.2(1) and especially AARM B.2(1.a)).
+
+B.2(1.a) looks a lot like 13.7(2.a/2), and the identifiers in System do appear
+in Annex Q.  
+
+But I'll allow there are other differences there.  13.7(2) says "The following
+language-defined library package exists" about System, while B.2(2) doesn't use
+the word "language-defined".  Also, the description of
+No_Implementation_Identifiers lists System in the same category as
+Interfaces.C. 
+
+I guess it seems a bit odd to have an identifier that is
+"implementation-defined" as opposed to language-defined, but that the language
+requires implementations to define (since it's in the Implementation
+Requirements section).  Also, the language does seem to define what the
+identifier is supposed to do.  Perhaps these identifiers are is in some
+in-between state between language-defined and implementation-defined---a
+"Schrödinger's Identifier", maybe?  
+
+Anyway, I was just wondering if the omission was a typo.  If there's a reason
+behind it, that's OK with me (I don't normally look things up in Annex Q
+anyway).
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February  5, 2014  8:04 PM
+
+... 
+> I guess it seems a bit odd to have an identifier that is 
+> "implementation-defined" as opposed to language-defined, but that the 
+> language requires implementations to define (since it's in the 
+> Implementation Requirements section).  Also, the language does seem to 
+> define what the identifier is supposed to do.  Perhaps these 
+> identifiers are is in some in-between state between language-defined 
+> and implementation-defined---a "Schrödinger's Identifier", maybe?
+
+I think that's right. The problem here is while there is a requirement that
+an implementation define a function Rotate_Left, the first argument to it has
+a type that is clearly implementation-defined. (Most implementations will have
+Unsigned_8, but other possibilities exist: our U2200 implementation had
+Unsigned_9 but no Unsigned_8, for instance.) So it's in a weird limbo halfway
+between language-defined and implementation-defined. Since 13.12.1 comes down
+on the side of implementation-defined, the Annex Q indexes do the same.
+
+> Anyway, I was just wondering if the omission was a typo.  If there's a 
+> reason behind it, that's OK with me (I don't normally look things up 
+> in Annex Q anyway).
+
+The omission from the main index was clearly an oversight (although "rotate"
+and "shift" are indexed). The omission from Annex Q was on purpose, I think.
+
+***************************************************************
+
+Editor's note (February 5, 2014): All of the items above this
 marker have been included in the working version of the AARM.
 
 ****************************************************************