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

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

--- ai12s/ai12-0302-1.txt	2019/06/11 01:15:27	1.3
+++ ai12s/ai12-0302-1.txt	2019/10/02 00:04:11	1.4
@@ -1,4 +1,4 @@
-!standard A(15)                                  19-05-31  AI12-0302-1/02
+!standard A(15)                                  19-10-01  AI12-0302-1/03
 !class Amendment 19-01-10
 !status work item 19-01-10
 !status received 19-01-10
@@ -8,13 +8,14 @@
 !summary
 
 Language-defined units declared as Pure will be implicitly Global =>
-null. Other packages (generic or not) will have Global => synchronized
-in out <unit>. Subprograms that refer to the internal state of an
-object identified by some sort of handle passed as a parameter (e.g.
-File_Type and Generator), will have Global => in [out] <param>.all.
-IO routines that refer implicitly to Current_Input or Current_Output
-will have Global => in out Text_IO, meaning they will likely conflict with
-one another.
+null. Other (nongeneric) packages will have Global => synchronized in
+out <unit>. Generic packages will have Global => synchronized in out
+<unit> & <formal1>'Global & <formal2>'Global ...  Subprograms that
+update the internal state of a "compound" object identified by an "in"
+parameter (e.g. File_Type and Generator), will have Global => overriding
+in out <param>. IO routines that refer implicitly to Current_Input or
+Current_Output will have Global => in out Text_IO, meaning they will
+likely conflict with one another.
 
 !problem
 In the absence of a Global aspect, the default is "Global => in out all"
@@ -24,26 +25,30 @@
 
 !proposal
 For language-defined units declared Pure, we will have the implicit
-Global => null. For others, we will insert an explicit:
+Global => null. For other nongeneric packages, we will insert an explicit:
 
    Global => synchronized in out <unit_name>
 
-where <unit_name> is the name of the package or generic package for
-which the Global aspect is specified. For library (generic) subprograms
-that are not merely renames of some subprogram declared elsewhere, the
-<unit_name> will refer to the parent package (or generic package) of the
-library (generic) subprogram.
+where <unit_name> is the name of the package for which the Global aspect
+is specified. For generic packages, the Global aspects of appropriate
+generic formals will be "concatenated" to the "synchronized in out
+<unit_name>". For library (generic) subprograms that are not merely
+renames of some subprogram declared elsewhere, the <unit_name> will
+refer to the parent package (or generic package) of the library
+(generic) subprogram, plus appropriate Global aspects of generic formal
+parameters.
 
 Below are two lists of the language-defined units. The first list is
 those declared Pure. The second list is of those not declared Pure.
 We have reviewed the second list and made certain that "Global =>
-synchronized in out <unit_name>" is appropriate for each. Some will
+synchronized in out <unit_name>" is appropriate for each, possibly
+with Global aspects for generic formals concatenated. Some will
 have individual operations that can be specified as Global => null,
 if their result is purely a function of their inputs. And some, in
 particular in the I/O packages, will need to indicate their use of an
 unknown, unsynchronized global corresponding to Current_Input or
 Current_Output, as explained in RM A(3.1/4). For these, ideally we
-could write either:
+could write something like:
 
     Global => (in out Current_Input.all, synchronized in out Text_IO)
 or
@@ -62,46 +67,31 @@
 would be considered to conflict.
 
 A more general problem has to do with parameters that are clearly
-"handles" or equivalent, such as a File_Type, random number Generator,
-or a task object. Even though they are passed as IN parameters, the
-subprogram can clearly update their associated state. One choice is to
-consider all of this state as residing, unsynchronized, in the
-associated package, as we did above for Current_Input and
-Current_Output, but that would be painful, since none of the, for
-example, File operations would be independent even when the Files
-designate distinct internal files. Instead, as part of AI12-0240-6, we
-have explicitly permitted a global_name to be of the form X.all, where X
-statically denotes an object, including possibly a formal parameter.
-Hence, Put, Get, and Col become:
+"handles" or equivalent on a "compound" object, as defined in
+AI12-0240-6, such as a File_Type, random number Generator, or a task
+object. Even though they are passed as IN parameters, the subprogram can
+clearly update their associated state. One choice is to consider all of
+this state as residing, unsynchronized, in the associated package, as we
+did above for Current_Input and Current_Output, but that would be
+painful, since none of the, for example, File operations would be
+independent even when the Files designate distinct internal files.
+Instead, as part of AI12-0240-6, we have explicitly permitted the notion
+of "overriding" an IN mode with a mode that reflects the effect on the
+underlying "compound" object. Hence, Put and Get become:
 
   procedure Put (File : File_Type; Item : String)
-    with Global => in out File.all;
+    with Global => overriding in out File;
 
   procedure Get (File : File_Type; Item : out String)
-    with Global => in out File.all;
+    with Global => overriding in out File;
 
-  function Col (File : File_Type) return Positive_Count
-    with Global => in File.all;
-
-Note that we need to mention File.all in the Global aspect for Col, because
-it is reading state updated by Put and Get. When the File is itself of
-"in out" mode, we don't need any Global aspect, because clearly changing
-File as a whole can cause us to refer to completely new file position
-information. The model is that data that is affected by Open/Close,
-such as the associated Name, will logically reside "directly" within
-the File_Type object. For data that is affected by Read/Write, such
-as Col and Line, it will reside in an object that is *designated* by
-some part of the File_Type object, allowing the use of an IN parameter.
-
 Using the same approach, Random becomes:
 
   function Random(Gen : Generator) return Result_Subtype
-     with Global => in out Gen.all;
+     with Global => overriding in out Gen;
 
-To be consistent, presuming the actual "seed" resides at Gen.all, we also
-need to add Global references to Gen.all for all of the various Reset
-procedures (in out Gen.all), the Save procedure (in Gen.all), and the
-Image function (in Gen.all).
+Similarly, the various Reset procedures will have
+   ... with Global => overriding in out Gen;
 
 Finally, we have functions that return generalized references into
 another object, e.g.:
@@ -122,8 +112,9 @@
 
 So to summarize the wording, each library unit will have a well-defined
 Global aspect at the package level, being either implicitly "null" for
-pure library units, or explicitly "synchronized in out <unit_name>"
-for impure library units (see list of impure units below).
+pure library units, or explicitly "synchronized in out <unit_name> &
+<formal1>'Global & ..." for impure library units (see list of impure
+units below).
 
 And then within the impure units, individual subprograms may override
 this default with "null" when they are certain to have no side effects
@@ -133,6 +124,8 @@
 *not* synchronized, and "in [out] <param>.all" when they refer to the
 variable state associated with a dereference of an IN parameter.
 
+OVERRIDING PARAMETER MODES
+
 Here are the details for subprograms with side effects that cannot use
 the default associated with the enclosing impure library unit (ignoring
 side-effect free subprograms for now):
@@ -140,41 +133,29 @@
 Within 13.11.4, Subpools:
 
 Modify Set_Pool_Of_Subpool, Allocate_From_Subpool to have:
-  with Global => in out Subpool.all;
-
-Modify Pool_Of_Subpool to have:
-  with Global => in Subpool.all;
+  with Global => overriding in out Subpool;
 
 ---
 
 Within A.5.2, Discrete_Random and Float_Random:
 
 Modify Random, Reset to have
-  with Global => in out Gen.all;
+  with Global => overriding in out Gen;
 
-Modify Save, Image to have
-  with Global => in Gen.all;
-
 ---
 
 Within A.8.1, Sequential_IO:
 
 Modify Flush, Read, Write to have
-  with Global => in out File.all;
-
-Modify End_Of_File to have
-  with Global => in File.all;
+  with Global => overriding in out File;
 
 ---
 
 Within A.8.4, Direct_IO:
 
 Modify Flush, Read, Write, Set_Index to have:
-  with Global => in out File.all;
+  with Global => overriding in out File;
 
-Modify Index, Size, End_Of_File to have:
-  with Global => in File.all;
-
 ---
 
 Within A.10.1, Text_IO:
@@ -195,7 +176,7 @@
   Put, Get, Put_Line, Get_Line, Look_Ahead, Get_Immediate
 
 to have
-  with Global => in out File.all;
+  with Global => overriding in out File;
 
 Modify current input/output versions of:
 
@@ -205,24 +186,33 @@
 to have
   with Global => in Text_IO;
 
-Modify File_Type versions of:
-
-  Line_Length, Page_Length, End_Of_Line, End_Of_Page,
-  End_Of_File, Col, Line, Page
-
-to have
-  with Global => in File.all;
-
 ---
 
 Within A.12.1, Stream_IO:
 
 Modify Read, Write, Set_Index to have:
-  with Global => in out File.all;
+  with Global => overriding in out File;
+
+
+GLOBAL ASPECTS ON GENERIC UNITs
 
-Modify End_Of_File, Index, Size to have:
-  with Global => in File.all;
+As a general rule, all language-defined generic units will include
+"<formal_type_or_subp1>'Global & <formal_type_or_subp2>'Global & ..." as
+part of their unit-level Global aspect.  For pure generic units, that
+is all that will appear.  For impure generic units, this will be
+prefixed with "synchronized in out <unit-name> & ".
 
+Here is a list of exceptions to this general rule:
+
+Generic_Elementary_Functions, Generic_Complex_Types,
+Complex_Elementary_Functions, Generic_Real_Arrays, and
+Generic_Complex_Arrays can have simply:
+
+   Global => null
+
+because the base subtype of the formal "Real" subtype is what is used, and
+the base subtype has any predicates stripped off.
+
 ---
 
 ---------------
@@ -490,9 +480,9 @@
 as proposed above, we will specify the side effects using an appropriate
 Global aspect. Also, for cases where a parameter mode of IN is used for
 an operand that clearly is associated with updatable state, a Global
-aspect of the form Param.all will be used to capture the fact that some
-potentially non-synchronized state is being updated that is designated
-by the given Param.
+aspect of the form OVERRIDING IN OUT Param will be used to capture the
+fact that some potentially non-synchronized state is being updated that
+is designated by the given Param.
 
 See the !proposal for more discussion and rationale.
 
@@ -560,5 +550,29 @@
 Randy: AI12-0112-1 handles all of the containers, including individual
 operations in many cases, so this AI doesn't need to mention them (other than
 that info).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, October 1, 2019  3:31 PM
+
+Here is an update to the AI defining the Global aspect for language-defined
+units.  It incorporates the new "overriding" notion of the latest AI12-0240-6,
+and tries to address the issue of generic units more completely.
+
+[This is version /03 of the AI - Editor.]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 1, 2019  7:03 PM
+
+You're still missing the note that AI12-0112-1 handles all of the container's
+Globals, including more specific ones when possible. You wouldn't want to list
+out all of the possibilities I came up with! - there's "null" (for pure
+navigation functions), the default of the package, "access <container type>",
+some with specific formal parameters, and some combinations.
+
+The fact that this is not handled in this AI needs to be mentioned in this AI.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent