CVS difference for ai05s/ai05-0060-1.txt
--- ai05s/ai05-0060-1.txt 2008/01/29 02:51:08 1.4
+++ ai05s/ai05-0060-1.txt 2008/01/31 03:02:19 1.5
@@ -1,5 +1,8 @@
-!standard E.2.2(9/1) 08-01-28 AI05-0060-1/01
+!standard E.2(14) 08-01-30 AI05-0060-1/02
+!standard E.2.2(9/1)
!standard E.2.2(9.2/1)
+!standard E.2.2(14/2)
+!standard E.2.2(18)
!class binding interpretation 07-08-04
!status work item 07-08-04
!status received 07-06-19
@@ -20,6 +23,9 @@
but they themselves cannot be used remotely except within the context of
the containing construct.
+Remote access types can be non-controlling formal parameters to primitive
+subprograms of other remote access to class-wide types.
+
Class wide access to limited interfaces (including synchronous, task,
and protected interfaces) should be allowed as remote access types.
@@ -50,6 +56,12 @@
Remote_Types pragmas, as we wouldn't have to worry about the effect on most
implementations.
+(4) E.2.2(14/2) states that access parameters are only allowed for the primitive
+subprograms of a remote access to class-wide types if they are controlling parameters,
+yet it seems to be useful to have non-controlling formal parameters that are remote access
+types to allow peer to peer systems. Should we allow remote access types to be passed as
+parameters to subprograms declared in Remote Types Library units? (Yes.)
+
!recommendation
(See Summary.)
@@ -108,13 +120,121 @@
!discussion
-The solution requires care, as a non-limited type can be derived from a limited interface
-type. That would violate the intent that a remote access type can only designate a limited
-object.
-
-Excluding anonymous access types also requires care: if one appears as a component of a
-remote type, the remote type ought to be required to have user-defined stream attributes
-(that is, any exclusion should not change the rules for external streaming).
+Ada 2005 introduces interfaces and expanded usage of anonymous access types
+to the language. Annex E appears to rule out the use of interfaces as remote
+access types and lacks clarity in defining how access discriminants, access
+parameters, and access components can be used in a remote types library unit.
+
+Ada 2005 also introduces new standard libraries such as the container libraries.
+Many of these library units appear to be good candidates to become remote type
+library units. AI05-0084 looks at how this could be done. However, not all
+implementations conform to Annex E, and making these library units remote type
+library units would place restrictions on the units that could cause an implementor
+to have to redesign the corresponding library_unit_body in many cases. An
+implementor should not have to comply with these restrictions if their
+implementation does not conform to Annex E. To minimally impact implementations
+that do not care about Annex E, an allowance is needed in the RM to relax the
+restrictions for those cases. Specifying that an implementor is allowed to
+comment out the Annex E pragmas in standard libraries seems to be the best way
+to do this in a consistent manner. Such an approach would not involve any changes
+to the compiler, and makes it more clear that the implementor is not conforming
+to Annex E restrictions.
+
+The main focus of this AI is to clarify the definition of remote types and remote
+access types.
+
+The model of a remote access type is that of a remote handle to an object that
+can only be operated through the use of remote dispatching calls. Components
+of the object cannot be remotely accessed directly, only indirectly though the
+dispatching calls. This is why the existing rules restrict remote access types
+to only designate private tagged types that are limited in nature whereby all
+components of the type are private.
+
+A limited interface type mostly satisfies these basic constraints. A limited
+interface does not have any visible components and is a tagged type. One main
+difference is that it is possible to derive a nonlimited type from a limited
+interface while it is not possible to derive a nonlimited type from a limited
+type. If remote access types are allowed to designate limited interface types,
+then this would mean that the value of a remote access to class-wide limited
+interface can be an object of a nonlimited type derived from the interface. The
+remote (client) view view of the object would still be the equivalent of a
+limited view however, because of rule E 2.2 16/1 which states that 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. The local (server) view
+of the object could be a nonlimited view. This would would mean it could be
+possible to assign the object locally to a local variable, and that the object
+could be assigned a new value locally. This capability seems to be potentially
+useful and no issues could be found with allowing such usage.
+
+The other main difference between a value of a limited interface and a value of a
+limited private tagged type is that the value of a limited interface can designate
+a protected type or a task type, since synchronous interfaces, task interfaces,
+and protected interfaces are all considered limited interface types. Also,
+E.2.2(9.3/1) states that a type that is derived from a remote access type is a
+remote access type. Therefore we need to consider whether such interface types
+can be used as remote access types. The first point to consider is that E.4 (17)
+states that all forms of remote subprogram calls are potentially blocking
+operations. This would seem to rule out interfaces where primitive subprograms are
+implemented by protected subprograms, since protected subprograms are not
+supposed to be potentially blocking operations. Interfaces could be used however,
+where the primitive subprograms are implemented by normal subprograms, (i.e., not
+implemented by protected subprograms or task entries), since these sorts of calls
+can be potentially blocking. Such calls could call protected subprograms of the
+object directly.
+
+On the surface, being able to call task entries and protected entries remotely seems
+to be a powerful construct. Furthermore, such a language feature might allow the
+possibility of requeuing an entry to a remote object. For example, this could
+facilitate distributed applications whereby requests made to a central server
+are requeued to available replicated worker servers on a network. It is felt at
+this time that implementing remote requeue and remote entry calls would be quite
+difficult to implement. Such capability would be worth considering in a separate
+AI and dealt with using a different time schedule than would be needed to implement
+the changes needed for this AI. Therefore, the approach for now is to disallow
+remote entry calls until such time that such a feature could be introduced to
+the language. As a result, the wording for this AI will disallow remote access
+types of limited interface types where primitive subprograms are implemented by
+either protected subprograms or entries.
+
+Another question has to do with defining how the various kinds of access types can
+be used in a remote types package. The existing definition states that all access
+types declared in a remote access types declaration are remote access types. This
+does not fit well with anonymous access types such as access discriminants, access
+parameters, and access components. In particular, anonymous access discriminants
+and access components typically are not accessed remotely except through the
+containing construct.
+
+Certain types defined in remote types library units are not intended to be used as
+remote access types but only as remote types that can be passed by value remotely
+as parameters to a remote call. Such types might include primitives that accept
+anonymous access to subprogram parameters that are intended to be used only locally.
+For example, the standard container libraries have an Update_Element primitive
+subprogram that accepts an anonymous access to subprogram parameter. It is
+possible to conceive an interface however where an access to a remote subprogram
+is desired instead. There needs to be a way to distinguish between these usages.
+Since most anonymous access types are only intended to be used locally,
+limiting remote access types to be only named access types provides a clean way
+to distinguish usages.
+
+The final point is that E.2.2(14/2) rules out passing remote access types as
+parameters to other remote access types. This seems unintentional as it would
+be useful to pass handles to objects around remotely to allow dynamic objects to
+call each other. For example a peer to peer system could be setup where
+various remote objects could register with a central server using an RCI package.
+The central server could act as a switchboard, connecting client objects to each
+other by calling primitive registration subprograms of the objects passing in a
+cached handle to the other peer as a remote access type. To allow such usage,
+E.2.2(14/2) needs to be relaxed to allow remote access type parameters to be passed
+as non-controlling formal parameters to primitive subprograms of a remote
+access-to-class-wide type.
+
+Overall, being able to use limited interfaces as remote access types seems like a
+useful capability that can be added to the language with a relatively low level
+of effort. This AI may pave the way for future capabilities such as remote entry
+calls, and remote requeue which might give Ada a further advantage over
+other languages. It may be that using limited interfaces as remote access types
+could become the preferred way to do remote calls.
-- !corrigendum E.2.2(9/1)
@@ -788,3 +908,112 @@
****************************************************************
+From: Brad Moore
+Sent: Wednesday, January 30, 2008 2:05 PM
+
+When reviewing the proposed wording changes of AI05-0060, I realized there
+was a side benefit of one of the changes that has not yet been discussed,
+and seemed worthy of discussion.
+
+I have added the following question to the AI.
+
+E.2.2(14/2) states that access parameters are only allowed for the primitive
+subprograms of a remote access to class-wide types if they are controlling
+parameters, yet it seems to be useful to have non-controlling formal
+parameters that are remote access types to allow peer to peer systems.
+Should we allow remote access types to be passed as parameters to
+subprograms declared in Remote Types Library units? (Yes.)
+
+
+E.2.2(14/2) rules out passing remote access types as parameters to other remote
+access-to-class-wide types. This seems unintentional as it would be useful to
+pass handles to objects around remotely to allow dynamic objects to call each
+other. For example a peer to peer system could be setup where various remote
+objects could register with a central server using an RCI package. The central
+server could act as a switchboard, connecting client objects to each other by
+calling primitive registration subprograms of the objects passing in a cached
+handle to the other peer as a remote access type. To allow such usage,
+E.2.2(14/2) needs to be relaxed to allow remote access type parameters to be passed
+as non-controlling formal parameters to primitive subprograms of a remote
+access-to-class-wide type.
+
+I was proposing changing this rule 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);
+
+Does anyone see any reasons why you shouldn't be able to pass remote access types
+to non-controlling formal subprograms of a remote-access-to-class-wide type?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, January 30, 2008 5:08 PM
+
+I think this is a bit confused. Remote access types
+may already be passed between partitions. E.2.2(14/2)
+is saying that the primitive subprograms of the
+*designated* type of a remote access type may only
+have access parameters if they are controlling
+parameters. They can certainly have parameters
+of a *named* access type, including the same remote
+access-to-class-wide type, so long as the type is
+externally streamable. Remote access types are
+by definition externally streamable.
+
+Unfortunately, I see that we lost the critical fact
+that remote access types are externally streamable
+in the Ada 2005 process! (Randy are you listening?)
+E.2.2(8/2) dropped the wording mentioning that only
+access types that are *non*-remote need user-defined
+read/write routines. Probably the right fix for this
+is to change the definition in 13.13.2 for externally
+streamable to include all remote access types
+automatically. That fix probably should be its own AI.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 30, 2008 5:26 PM
+
+How soon they forget!! We approved such an AI (AI05-0065-1) at the meeting
+in Fairfax. Indeed, if you were using the working version of the AARM
+(available online only and only for ARG members) you would notice the
+updated wording in 13.13.2(52/3).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, January 30, 2008 5:41 PM
+
+Wow. My brain really is slipping...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 30, 2008 8:42 PM
+
+> ...
+> * 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);
+
+This change doesn't make sense. An access parameter is always an anonymous
+access (sub)type (parameters of named access types are *not* access
+parameters, see 6.1(24/2) for the formal definition of "access parameter".
+OTOH, your revised E.2.2(9/1) says that a remote access type is always a
+named access type. Thus, an access parameter can never be a "remote access
+type parameter" (whatever that is). So this is talking about apples and
+oranges and the addition adds nothing other than confusion.
+
+I suppose you could allow anonymous access types to *be* remote access types
+in very limited circumstances (presumably only for access-to-classwide), but
+that would need very different wording. And it's not clear that it is a good
+idea: I would think that it would be best to have only one type of remote
+"handle"; having a bunch of anonymous ones and converting between them
+surely would add complications without an obvious benefit.
+
+****************************************************************
Questions? Ask the ACAA Technical Agent