CVS difference for ai05s/ai05-0060-1.txt

--- ai05s/ai05-0060-1.txt	2008/01/19 07:25:31	1.3
+++ ai05s/ai05-0060-1.txt	2008/01/29 02:51:08	1.4
@@ -1,4 +1,4 @@
-!standard E.2.2(9/1)                                   07-08-04    AI05-0060-1/00
+!standard E.2.2(9/1)                                   08-01-28    AI05-0060-1/01
 !standard E.2.2(9.2/1)
 !class binding interpretation 07-08-04
 !status work item 07-08-04
@@ -10,8 +10,22 @@
 
 !summary
 
-** TBD **
+The RM should formally state implementations do not need to utilize
+or support Annex E pragmas in standard library library_unit_declarations
+if the implementation does not support Annex E.
+
+The definition of remote access types is clarified to only apply to
+named access types. Anonymous access types may be used as access
+discriminants, access parameters, and access components of remote types, 
+but they themselves cannot be used remotely except within the context of
+the containing construct.
 
+Class wide access to limited interfaces (including synchronous, task,
+and protected interfaces) should be allowed as remote access types.
+
+The value of a remote access to class-wide limited interface can be
+an object of a nonlimited type derived from the interface.
+
 !question
 
 (1) E.2.2(9-9.2/1) define what a remote access type can designate. This does not include
@@ -41,8 +55,56 @@
 (See Summary.)
 
 !wording
+
+Add a new paragraph after E.2(14):
+
+   An implementation may insert a comment preceding Annex E pragmas in
+   library_unit_declarations of standard library packages if the implementation
+   does not conform to Annex E. The corresponding library_unit_body and the
+   private part(s) of the library_unit_declaration, if present, would then not
+   need to adhere to the restrictions that otherwise would have been imposed by
+   the pragmas.
+   
+
+Modify E.2.2(9/1) as follows:
+
+   A[n] {named} access type declared in the visible part of a remote types or
+   remote call interface library unit is called a remote access type. 
+   Such a type shall be:
+
+
+Modify E.2.2(9.2/1) as follows:
+
+   * a general access type that designates a class-wide limited private type
+     {or a class-wide limited interface type} or a class-wide private [type]
+     extension all of whose ancestors are either private [type] extensions
+     {, limited interface types,} or limited private types.
+
+
+Modify E.2.2(14/2) as follows:
+
+   * The primitive subprograms of the corresponding specific [limited private]
+     type shall only have access parameters if they are controlling formal
+     parameters {or remote access type parameters}; each non-controlling
+     formal parameter shall support external streaming (see 13.13/2); 
+
+Add a new paragraph after E.2.2(14/2):
+
+   * The primitive subprograms of the corresponding specific type shall not be
+     implemented by protected subprograms or entries.
+
+Add three new paragraphs after E.2.2(18)
+
+   6 Anonymous access types may be used as access discriminants, access parameters,
+   and access components of remote types, but they themselves cannot be used remotely
+   except within the context of the containing construct.
+
+   7 The value of a remote access to class-wide limited interface can be an object
+   of a nonlimited type derived from the interface.
 
-** TBD **
+   8 A remote access type may be a class-wide synchronized interface type, a 
+   class-wide protected interface type, or a class-wide task interface type, since
+   these interface types are limited interface types.
 
 !discussion
 
@@ -550,6 +612,179 @@
 multiple threads potentially spread across multiple partitions.
 One might even go so far as to recommend using synchronized
 interfaces when doing things remotely.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Thursday, January 24, 2008  9:48 AM
+
+>Based on my answers below, I don't see any insurmountable problems.
+>Concocting "stub" protected/task types might be a bit tricky,
+>but I suspect you could just make them very simple, with
+>all of the interesting information accessible via an access
+>discriminant.
+
+Remote Synchronous access types seem to be potentially quite useful.
+Since you can foresee a way to implement that might not be too
+difficult, I will plan to write up the AI assuming that synchronous
+interfaces are to be allowed, and see where that goes. I actually
+think it will be easier to write up that way because there would be
+less impact on the wording in the RM.
+
+>> A couple of points to add to the discussion so far;
+>>
+>> E.4 (17) states "All forms of remote subprogram calls are potentially
+>> blocking operations (see 9.5.1)."
+>>
+>> If protected interfaces were to be allowed as remote access types it
+>> would seem to imply that all procedures of the interface would need to
+>> be implemented as entries to work with the model of the protected types.
+
+>I don't see this.  Remember that there are three possibilities
+>with a primitive of a protected interface.  It can be implemented
+>directly as a protected subprogram, it can be implemented as
+>an entry (presuming it is visibly declared as a procedure), and
+i>t can be implemented as a "regular" subprogram which turns
+>around and calls one or more protected operations.  The only
+>one of these that is non-blocking is the one that is implemented
+>directly as a protected subprogram.
+
+Right. I agree. I missed regular subprograms. Same goes for function calls.
+
+>> Maybe functions and procedures could be implemented as regular
+>> subprograms, but those would be local calls that could call entries of
+>> the protected object which would be remote.
+
+>Sorry, I don't follow this.  If it is an access-to-remote
+>subprogram, then any dispatching call is a remote call.
+>Once you get to the "other" side, then you would call the
+>implementing subprogram/protected-operation.
+
+Please disregard. I was assuming the synchronized interface idea wouldn't
+fly and was fishing for ideas that might salvage the concept, but hadn't
+thought them through fully.
+
+>My conclusion is that using synchronized interfaces
+>is not a big problem, but that the newly proposed pragma "Implemented"
+>(or whatever it is called) could not specify "By_Entry" or
+>"By_Protected_Procedure" for these, since trying to
+>do a requeue on one of these or expecting non-blocking
+>behavior would be too difficult to accomplish.
+
+The concept of Remote requeues seems like a powerful one. For example
+I am thinking of a centralized broker type server that can requeue
+requests to any of a number of available servers distributed on a network. 
+
+It sounds like remote requeue would be difficult to implement now, but
+would be worth revisiting at some point in the future. In the meantime,
+the pragma "Implemented By_Entry" (or whatever it is called) could be
+required to disallow remote requeue until such  point that remote
+requeueing is added to the language. That issue can be covered in the
+AI that deals with the proposed new pragmas, so I will plan to write
+up the AI on using limited interaces as remote access types without
+mentioning remote requeue. Remote Requeue seems like an issue deserving
+its own AI. The AI on the new Implemented pragmas should cover remote
+requeue for now.
+
+>And in fact, it would seem highly
+>desirable to use synchronized interfaces for remote interfaces,
+>so they could support concurrent simultaneous access from
+>multiple threads potentially spread across multiple partitions.
+>One might even go so far as to recommend using synchronized
+>interfaces when doing things remotely.
+
+Indeed. This sounds to me like a very interesting growth area for Ada
+to explore and consider for the future.
+
+****************************************************************
+From: Brad Moore
+Sent: Thursday, January 24, 2008  10:25 AM
+
+One of the areas of investigation for AI05-0060-1 involve the 
+question of how non-limited types derived from limited 
+interfaces should be treated with respect to remote access 
+types. Should they be allowed or disallowed?
+I have been looking at this, and my current thoughts are that
+they should be allowed.
+ 
+My reasoning is as follows;
+ 
+From a remote perspective, access to a remote classwide type were
+designed to be viewed with the semantics of a limited private type.
+That is, the access is like a handle. One cannot access components
+of the remote type directly, all functionality is accessed through
+remote dispatching calls on the handle.
+ 
+Also, it is important to disallow predefined assignment. An application
+should not need to be linked with the implementation of a remote type.
+A remote application should only need to know the specification or the
+interface to a remote type.
+ 
+Currently the RM ensures these qualities by requiring access type
+declaration in Remote_Type packages to be limited and only extenstions
+of private types or private types.
+ 
+We need to ensure that if we allow limited interface types to be used as
+remote access types, that non-limited derivations can be used without
+breaking the above properties. That is, it should not be possible to
+assign such a remote access type to another variable.
+ 
+I believe this is covered already by the existing rules. In particular;
+ 
+E 2.2 16/1 - A value of a remote access-to-class-wide type shall be
+dereferenced (or implicitly converted to an anonymous access type) only
+as part of a dispatching call where the value designates a controlling
+operand of the call (see E.4, “Remote Subprogram Calls”).
+
+The difference appears to me that before, this rule mostly came for free
+by implementing rule E 2.2 9 - 9.2/1 
+
+E.2.2 9/1 An access type declared in the visible part of a remote types or
+remote call interface library unit is called a remote access type. Such a
+type shall be:
+
+E.2.2 9.1/1 an access-to-subprogram type, or
+
+E.2.2 9.2/1 a general access type that designates a class-wide limited
+private type or a class-wide private type extension all of whose ancestors
+are either private type extensions or limited private types.
+
+Now the implementation would need to ensure that if the object assigned
+to the access type is non-limited that E 2.2 16/1 still applies. It sounds
+to me like this would not be too difficult to implement. If you know the
+base type is both remote and limited then normal dereferencing should
+be disallowed.
+
+If we allow non-limited derived objects to be used with limited interface
+remote access types then I am thinking the RM would not need any additional
+changes to support this, (other than those needed already to support
+limited interface remote access types). Maybe there would need to be some
+note added to the AARM to explain this.
+
+On the other hand, if we want to disallow non-limited derived objects to be
+used as access to remote limited interface, then I think there would need
+to be an additional rule added to disallow this usage.
+
+I can see a need to be able to derive a non-limited type from a limited
+interface, and use assignment locally, but remotely only allow dispatching
+calls. This would let a programmer have the best of both worlds, and not
+be forced to choose between making a type non-limited or remote.
+ 
+Does anyone see a problem with this approach?
+ 
+If not, I will write up the AI assuming that non-limited derived objects
+can be assigned to remote access to limited interfaces.
+ 
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 24, 2008  12:32 PM
+
+I see no reason that the implementing type for
+a remote access-to-limited-interface needs itself
+to be limited.  The limitness is important on the
+client side, but doesn't seem important on
+the server side.
 
 ****************************************************************