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

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

--- ai12s/ai12-0353-1.txt	2020/01/11 00:03:15	1.1
+++ ai12s/ai12-0353-1.txt	2020/05/02 03:43:14	1.2
@@ -1,274 +1,275 @@
-!standard 6.1.2(14/5)                      20-01-10    AI12-0353-1/01
-!standard 6.1.2(15/5)
-!standard 6.1.2(42/5)
-!standard 9.5(49/5)
-!class Amendment 20-01-10
-!status work item 20-01-10
-!status received 19-06-03
-!priority Low
-!difficulty Medium
-!subject Global and Nonblocking aspects and dispatching calls
-!summary
-
-Subprograms that make dispatching calls may define their Global
-and Nonblocking aspects in terms of their own references and calls
-on potentially blocking operations, combined with the Global
-and Nonblocking aspects of the particular dispatching operations
-they invoke on particular class-wide parameters or globals.
-The Global attribute of an object of a class-wide type has a
-special syntax that allows an identification of the dispatching
-operations invoked on the object.
-
-!problem
-
-Stream and Put_Image attributes internally make dispatching calls on the
-stream read/write routines, which can be user written. Nevertheless,
-'Image uses a predefined stream and the default implementation of 'Image
-should always be effectively Global => null. In general for a subprogram
-that internally makes dispatching calls, we probably need a way to
-specify its Global aspect in terms of the Global aspects of the
-dispatching calls performed on a given classwide object, in combination
-with the global references performed directly within the subprogram.
-
-!proposal
-
-(See Summary.)
-
-!wording
-
-Add after 6.1.2(14.a/5):
-
-  Syntax
-
-  A dispatching_operation_list is used to identify some or all of
-  the dispatching operations of a tagged type T.
-
-    dispatching_operation_list ::=
-        ALL
-      | /dispatching_/selector_name {, /dispatching_/selector_name}
-
-Add after 6.1.2(15.a/5):
-
-  A /dispatching_/selector_name within a dispatching_operation_list for
-  a tagged type T shall resolve to denote a view of one or more
-  primitive dispatching operations of T[Redundant:, declared immediately
-  within the declarative region in which T is declared].
-
-Add after 6.1.2(42/5):
-
-  For a prefix X denoting an object of a class-wide type T'Class,
-  the following attribute is defined:
-
-  X'Global(dispatching_operation_list)
-
-    X'Global(list) represents the union of the global variable set
-    associated with the first subtype of the tagged type T1 identified
-    by the tag of X, and the global variable sets of the dispatching
-    operations of T1 corresponding to the specified dispatching
-    operations of T (or all dispatching operations of T if the list is
-    the reserved word ALL); a reference to this attribute may only
-    appear within a global_aspect_definition. If a
-    /dispatching_/selector_name within the list denotes multiple
-    dispatching operations of T, the global variable sets of all of the
-    corresponding dispatching operations of T1 are included in the
-    union.
-
-Add after 9.5(49.b/5):
-
-  For a prefix X denoting an object of a class-wide type T'Class,
-  the following attribute is defined:
-
-  X'Nonblocking(dispatching_operation_list)
-
-    X'Nonblocking(list) represents the AND of the Nonblocking aspect of
-    the first subtype of the tagged type T1 identified by the tag of X,
-    and the Nonblocking aspects of the dispatching operations of T1
-    corresponding to the specified dispatching operations of T (or all
-    dispatching operations of T if the list is the reserved word ALL).
-    If a /dispatching_/selector_name within the list denotes multiple
-    dispatching operations of T, the Nonblocking aspects of all of the
-    corresponding dispatching operations of T1 are ANDed together.
-
-!discussion
-
-For a subprogram that internally performs dispatching calls on an object
-of whose tag is determined at the call site, it is essentially
-impossible to describe the Global or Nonblocking behavior independently
-of that caller-determined tag.  Therefore, we propose to allow a
-subprogram to indicate what dispatching operations it performs on a
-given object known to the caller, and then have the caller determine
-what are the implications with respect to Global and Nonblocking.
-
-!ASIS
-
-No ASIS impact.
-
-!ACATS test
-
-!appendix
-
-From: Randy Brukardt
-Sent: Monday, September 30, 2019  9:31 PM
-
-> Here is an update to AI12-0334-2, based on the minutes of the last ARG
-> meeting.
-
-I didn't see anything in here as how to fix the definition of the stream
-attributes. I suspect that you were planning to use X'Global to define the
-Global in terms of the parameter (somehow), but that has to be defined in the AI
---  by osmosis. (Ergo, we need a redefinition of X'Read
-with the appropriate Global applied.) This is probably a good thing anyway,
-since the use of X'Global is not obvious and an example is needed (which X'Read
-etc. would provide).
-
-I didn't notice any other issues (but I didn't try to figure out how much
-violence this does to the assume-the-worst/assume-the-best rules for
-Nonblocking, which were constructed assuming that Nonblocking is a type-related
-aspect).
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Tuesday, October 1, 2019  2:43 PM
-
-> Not sure what you mean by the "fix the definition of the string 
-> attributes".  Perhaps you meant "streaming attributes"?  But even 
-> then, I am not sure what you mean by "fix"?
-
-Yes, I meant "stream" (as in my following correction message).
-
-The problem is that the stream attributes don't have any Global or Nonblocking 
-aspects, so we need to somehow define what those are. If we don't, they 
-default to "all" and "false", and that obviously would be bad for at least 
-some uses. (If you're writing to a file, probably it doesn't matter, but if 
-you are writing to a buffer, you probably don't want to be forced into "all"
-if the buffer is a "null".)
-
-The original problem came from the definition of 'Image, but since we're 
-proposing to move that away from streaming, it isn't relevant anymore. But 
-it still seems nasty that any streaming forces "all" and "false". I think the
-reason you invented the "dispatching" Global was in part for these 
-attributes. But then you need to use them. :-)
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Tuesday, October 1, 2019  2:52 PM
-
-I note that in AI12-0334-1, I had the stream attributes explicitly get 
-"in out all" and "false", because it doesn't seem to be well-defined at all. 
-So I think it is best that you define what their Global and Nonblocking 
-aspects are (if you can do better than "in out all", please do).
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Tuesday, October 1, 2019  3:02 PM
-
-I guess I don't understand why we are defining these at all.  Perhaps what
-you are saying is that the *default* implementations need to have specified
-Global and Nonblocking.  Clearly if the user defines their own, they can 
-pretty much do whatever they want.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Tuesday, October 1, 2019  3:25 PM
-
-Stream attributes can be called via dispatching calls, so we need to know what 
-to use in that case. And definitely the default implementations need to be 
-specified. There's a few words on this topic in an AARM note in AI12-0334-1 
-(the counter-part to your AI that I wrote).
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Tuesday, October 1, 2019  3:55 PM
-
-I can understand the situation with default implementations.  I guess there are
-default implementations of S'Class'{Read,Write,Input,Output} that make 
-dispatching calls on the "appropriate" streaming attribute of the Item 
-parameter, so how those work should probably be specified.  But I think when 
-the user defines their own streaming subprogram, they have to define their 
-own Global aspect -- agreed?
-
-
-Given that, I propose to add the following after the definition of 
-X'Global(dispatching-op-list):
-
-
-  For the default implementation of a streaming attribute for an
-  elementary type (see 13.13.2), the Global aspect is
-  Stream'Global(Read) for the Read and Input aspects, and
-  Stream'Global(Write) for the Write and Output aspects, where Stream is
-  the formal parameter name for the stream parameter.  For the default
-  implementation of a streaming attribute for a composite type with
-  first subtype S, the Global aspect is S'Global & Stream'Global(Read)
-  for the Read and Input aspects, and S'Global & Stream'Global(Write)
-  for the Write and Output aspects.
-  
-    AARM Discussion: We require the Global aspect for a composite
-    (first) subtype to include any side-effects associated with
-    any non-default streaming attributes of subcomponents, other
-    than the usual side effects associated with reading/writing
-    the stream itself.  
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Tuesday, October 1, 2019  4:16 PM
-
-A call on S'{Read,Write,Input,Output} can be a dispatching call (see 3.9.2(1/2) 
-- this explicitly defines these as dispatching operations). We need to know the 
-Global and Nonblocking aspects for such a dispatching call, and it seems that 
-one has to assume an arbitrary user-defined routine could be called from such 
-dispatching.
- 
-Of course, any user-defined routine will have it's own Global/Nonblocking, and 
-it's fine for that to be used for statically bound calls (including all 
-untagged types). But I don't think that works for dispatching calls.
- 
-And of course something needs to be said for the class-wide attributes as 
-well, but that's a different concern than the one I was discussing.
- 
-The wording you have is fine as far as it goes, but more needs to be said as 
-noted above.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Tuesday, October 1, 2019  4:32 PM
-
-I've run out of time on this, and I have another commitment this evening.  I'll
-try to produce something more before the ARG meeting.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Wednesday, October 2, 2019  3:13 PM
-
-I think the fact that these are officially "dispatching operations" could mean 
-that you can pass a class-wide object to them and it will dispatch to the 
-"appropriate" type's streaming attribute.  I am frankly not sure whether 
-calling T'Read with an operand of type T'Class is exactly equivalent to 
-calling the T'Class'Read with the same operand.  I suppose we should 
-somewhere clarify that in the RM!
-
-In any case, we know the streaming attribute of a tagged type can be reached 
-from the default implementation of any ancestor's 'Class streaming attribute.
-That would imply that the Global'Class aspect should be more permissive (e.g.
-"in out all"), as should the Global aspect of the default implementations of 
-the 'Class streaming attributes.  Is that what you had in mind?
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Friday, January 10, 2019  12:36 PM
+!standard 6.1.2(14/5)                      20-01-10    AI12-0353-1/01
+!standard 6.1.2(15/5)
+!standard 6.1.2(42/5)
+!standard 9.5(49/5)
+!class Amendment 20-01-10
+!status No Action (14-0-0) 20-04-29
+!status work item 20-01-10
+!status received 19-06-03
+!priority Low
+!difficulty Medium
+!subject Global and Nonblocking aspects and dispatching calls
+!summary
 
+Subprograms that make dispatching calls may define their Global
+and Nonblocking aspects in terms of their own references and calls
+on potentially blocking operations, combined with the Global
+and Nonblocking aspects of the particular dispatching operations
+they invoke on particular class-wide parameters or globals.
+The Global attribute of an object of a class-wide type has a
+special syntax that allows an identification of the dispatching
+operations invoked on the object.
+
+!problem
+
+Stream and Put_Image attributes internally make dispatching calls on the
+stream read/write routines, which can be user written. Nevertheless,
+'Image uses a predefined stream and the default implementation of 'Image
+should always be effectively Global => null. In general for a subprogram
+that internally makes dispatching calls, we probably need a way to
+specify its Global aspect in terms of the Global aspects of the
+dispatching calls performed on a given classwide object, in combination
+with the global references performed directly within the subprogram.
+
+!proposal
+
+(See Summary.)
+
+!wording
+
+Add after 6.1.2(14.a/5):
+
+  Syntax
+
+  A dispatching_operation_list is used to identify some or all of
+  the dispatching operations of a tagged type T.
+
+    dispatching_operation_list ::=
+        ALL
+      | /dispatching_/selector_name {, /dispatching_/selector_name}
+
+Add after 6.1.2(15.a/5):
+
+  A /dispatching_/selector_name within a dispatching_operation_list for
+  a tagged type T shall resolve to denote a view of one or more
+  primitive dispatching operations of T[Redundant:, declared immediately
+  within the declarative region in which T is declared].
+
+Add after 6.1.2(42/5):
+
+  For a prefix X denoting an object of a class-wide type T'Class,
+  the following attribute is defined:
+
+  X'Global(dispatching_operation_list)
+
+    X'Global(list) represents the union of the global variable set
+    associated with the first subtype of the tagged type T1 identified
+    by the tag of X, and the global variable sets of the dispatching
+    operations of T1 corresponding to the specified dispatching
+    operations of T (or all dispatching operations of T if the list is
+    the reserved word ALL); a reference to this attribute may only
+    appear within a global_aspect_definition. If a
+    /dispatching_/selector_name within the list denotes multiple
+    dispatching operations of T, the global variable sets of all of the
+    corresponding dispatching operations of T1 are included in the
+    union.
+
+Add after 9.5(49.b/5):
+
+  For a prefix X denoting an object of a class-wide type T'Class,
+  the following attribute is defined:
+
+  X'Nonblocking(dispatching_operation_list)
+
+    X'Nonblocking(list) represents the AND of the Nonblocking aspect of
+    the first subtype of the tagged type T1 identified by the tag of X,
+    and the Nonblocking aspects of the dispatching operations of T1
+    corresponding to the specified dispatching operations of T (or all
+    dispatching operations of T if the list is the reserved word ALL).
+    If a /dispatching_/selector_name within the list denotes multiple
+    dispatching operations of T, the Nonblocking aspects of all of the
+    corresponding dispatching operations of T1 are ANDed together.
+
+!discussion
+
+For a subprogram that internally performs dispatching calls on an object
+of whose tag is determined at the call site, it is essentially
+impossible to describe the Global or Nonblocking behavior independently
+of that caller-determined tag.  Therefore, we propose to allow a
+subprogram to indicate what dispatching operations it performs on a
+given object known to the caller, and then have the caller determine
+what are the implications with respect to Global and Nonblocking.
+
+!ASIS
+
+No ASIS impact.
+
+!ACATS test
+
+!appendix
+
+From: Randy Brukardt
+Sent: Monday, September 30, 2019  9:31 PM
+
+> Here is an update to AI12-0334-2, based on the minutes of the last ARG
+> meeting.
+
+I didn't see anything in here as how to fix the definition of the stream
+attributes. I suspect that you were planning to use X'Global to define the
+Global in terms of the parameter (somehow), but that has to be defined in the AI
+-- it's not going to happen by osmosis. (Ergo, we need a redefinition of X'Read
+with the appropriate Global applied.) This is probably a good thing anyway,
+since the use of X'Global is not obvious and an example is needed (which X'Read
+etc. would provide).
+
+I didn't notice any other issues (but I didn't try to figure out how much
+violence this does to the assume-the-worst/assume-the-best rules for
+Nonblocking, which were constructed assuming that Nonblocking is a type-related
+aspect).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 1, 2019  2:43 PM
+
+> Not sure what you mean by the "fix the definition of the string 
+> attributes".  Perhaps you meant "streaming attributes"?  But even 
+> then, I am not sure what you mean by "fix"?
+
+Yes, I meant "stream" (as in my following correction message).
+
+The problem is that the stream attributes don't have any Global or Nonblocking 
+aspects, so we need to somehow define what those are. If we don't, they 
+default to "all" and "false", and that obviously would be bad for at least 
+some uses. (If you're writing to a file, probably it doesn't matter, but if 
+you are writing to a buffer, you probably don't want to be forced into "all"
+if the buffer is a "null".)
+
+The original problem came from the definition of 'Image, but since we're 
+proposing to move that away from streaming, it isn't relevant anymore. But 
+it still seems nasty that any streaming forces "all" and "false". I think the
+reason you invented the "dispatching" Global was in part for these 
+attributes. But then you need to use them. :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 1, 2019  2:52 PM
+
+I note that in AI12-0334-1, I had the stream attributes explicitly get 
+"in out all" and "false", because it doesn't seem to be well-defined at all. 
+So I think it is best that you define what their Global and Nonblocking 
+aspects are (if you can do better than "in out all", please do).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, October 1, 2019  3:02 PM
+
+I guess I don't understand why we are defining these at all.  Perhaps what
+you are saying is that the *default* implementations need to have specified
+Global and Nonblocking.  Clearly if the user defines their own, they can 
+pretty much do whatever they want.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 1, 2019  3:25 PM
+
+Stream attributes can be called via dispatching calls, so we need to know what 
+to use in that case. And definitely the default implementations need to be 
+specified. There's a few words on this topic in an AARM note in AI12-0334-1 
+(the counter-part to your AI that I wrote).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, October 1, 2019  3:55 PM
+
+I can understand the situation with default implementations.  I guess there are
+default implementations of S'Class'{Read,Write,Input,Output} that make 
+dispatching calls on the "appropriate" streaming attribute of the Item 
+parameter, so how those work should probably be specified.  But I think when 
+the user defines their own streaming subprogram, they have to define their 
+own Global aspect -- agreed?
+
+
+Given that, I propose to add the following after the definition of 
+X'Global(dispatching-op-list):
+
+
+  For the default implementation of a streaming attribute for an
+  elementary type (see 13.13.2), the Global aspect is
+  Stream'Global(Read) for the Read and Input aspects, and
+  Stream'Global(Write) for the Write and Output aspects, where Stream is
+  the formal parameter name for the stream parameter.  For the default
+  implementation of a streaming attribute for a composite type with
+  first subtype S, the Global aspect is S'Global & Stream'Global(Read)
+  for the Read and Input aspects, and S'Global & Stream'Global(Write)
+  for the Write and Output aspects.
+  
+    AARM Discussion: We require the Global aspect for a composite
+    (first) subtype to include any side-effects associated with
+    any non-default streaming attributes of subcomponents, other
+    than the usual side effects associated with reading/writing
+    the stream itself.  
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 1, 2019  4:16 PM
+
+A call on S'{Read,Write,Input,Output} can be a dispatching call (see 3.9.2(1/2) 
+- this explicitly defines these as dispatching operations). We need to know the 
+Global and Nonblocking aspects for such a dispatching call, and it seems that 
+one has to assume an arbitrary user-defined routine could be called from such 
+dispatching.
+ 
+Of course, any user-defined routine will have it's own Global/Nonblocking, and 
+it's fine for that to be used for statically bound calls (including all 
+untagged types). But I don't think that works for dispatching calls.
+ 
+And of course something needs to be said for the class-wide attributes as 
+well, but that's a different concern than the one I was discussing.
+ 
+The wording you have is fine as far as it goes, but more needs to be said as 
+noted above.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, October 1, 2019  4:32 PM
+
+I've run out of time on this, and I have another commitment this evening.  I'll
+try to produce something more before the ARG meeting.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, October 2, 2019  3:13 PM
+
+I think the fact that these are officially "dispatching operations" could mean 
+that you can pass a class-wide object to them and it will dispatch to the 
+"appropriate" type's streaming attribute.  I am frankly not sure whether 
+calling T'Read with an operand of type T'Class is exactly equivalent to 
+calling the T'Class'Read with the same operand.  I suppose we should 
+somewhere clarify that in the RM!
+
+In any case, we know the streaming attribute of a tagged type can be reached 
+from the default implementation of any ancestor's 'Class streaming attribute.
+That would imply that the Global'Class aspect should be more permissive (e.g.
+"in out all"), as should the Global aspect of the default implementations of 
+the 'Class streaming attributes.  Is that what you had in mind?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, January 10, 2019  12:36 PM
+
 Here is a simple cut and paste of the part of AI12-0334-2 that had to do with 
 global and nonblocking associated with subprograms that internally make 
 dispatching calls.  There is nothing new here.  Just an attempt to split this 
 off so it doesn't confuse other discussions. [This is version /01 of
 this AI - Editor.]
-
-****************************************************************
+
+****************************************************************

Questions? Ask the ACAA Technical Agent