!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 -- 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.] ****************************************************************