CVS difference for ai05s/ai05-0060-1.txt
--- ai05s/ai05-0060-1.txt 2008/02/05 02:33:25 1.7
+++ ai05s/ai05-0060-1.txt 2008/03/07 06:15:19 1.8
@@ -1,9 +1,10 @@
-!standard E.2(14) 08-02-04 AI05-0060-1/04
+!standard A(4) 08-02-26 AI05-0060-1/05
!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 ARG Approved 6-0-2 08-02-09
!status work item 07-08-04
!status received 07-06-19
!priority Low
@@ -18,26 +19,20 @@
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.
+named access types.
Remote access types should be allowed to designate class-wide limited interface
types (including synchronous, task, and protected interface types).
-The value of a remote access-to-class-wide limited interface type can be
-an object of a nonlimited type derived from the interface type.
+The value of a remote access-to-class-wide limited interface type can
+designate an object of a nonlimited type derived from the interface type.
-The use of remote access-to-class-wide interface types is recommended over
-the use of other remote access-to-class-wide types.
-
!question
(1) E.2.2(9-9.2/1) define what a remote access type can designate. This does not include
a class-wide interface. But an interface is very similar to an abstract tagged limited
private type; neither can have visible components. A class-wide limited private type
-is allowed in a remote access type. Shouldn't a limited interface be allowed?
+is allowed in a remote access type. Shouldn't a limited interface be allowed? (Yes.)
(2) It is possible to derive a nonlimited type from a limited interface type.
If remote access types are allowed to designate class-wide limited interface types,
@@ -50,18 +45,9 @@
This rule also enforces the object to be treated as though it is a private type, since
it disallows accessing components directly. If this rule enforces that remote access
is limited and private in nature, should we allow remote access types to designate
-all class-wide types? (Maybe, but if so, this should be dealt with in a separate AI)
-
-(4) Assuming we allow remote access-to-class-wide limited interface types, these types
-could be used in place of any other existing usages for remote access-to-class-wide types.
-Remote access types are really providing access to no more than the interface of an object.
-Should we recommend that remote access-to-class-wide types be use to designate only
-limited interface types? (Yes.) If so, should we formally say that the use of remote
-access-to-class-wide types that designate objects other than limited interface types is
-obsolescent in Annex J? (Maybe, but as this affects a different annex than the rest of
-the changes, that should be dealt with in a separate AI, if necessary)
+all class-wide types? (No.)
-(5) The definition of remote access types includes any anonymous access types that occur
+(4) The definition of remote access types includes any anonymous access types that occur
visibly in the remote types package. But such anonymous access types are necessarily
part of another construct (access discriminants, access parameters, access components);
they will not themselves be used remotely unless the containing construct is. But this
@@ -73,7 +59,7 @@
Should this restriction be relaxed? (Yes.)
-(6) Should we formally say that Annex E pragmas have no effect on implementations that
+(5) Should we formally say that Annex E pragmas have no effect on implementations that
don't support Annex E? (Yes.) Doing so would allow us to declare additional packages to have
Remote_Types pragmas, as we wouldn't have to worry about the effect on most
implementations.
@@ -84,15 +70,10 @@
!wording
-Add a new paragraph after E.2(14):
+Add a new paragraph after A(4):
- 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.
-
+ An implementation may omit pragma Remote_Types (see E.2.2) in language-defined
+ library units if the implementation does not conform to Annex E.
Modify E.2.2(9/1) as follows:
@@ -103,8 +84,8 @@
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]
+ * a general access type that designates a class-wide limited private type,
+ {, 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.
@@ -116,31 +97,21 @@
parameters; each non-controlling formal parameter shall support external
streaming (see 13.13/2);
-Add a new paragraph after E.2.2(14/2):
+Add a new paragraph after E.2.2(14/2): [Note: This depends on pragma Implemented,
+which was added by AI05-0030-2.]
- * The primitive subprograms of the corresponding specific type shall not be
- implemented by protected subprograms or entries.
+ * The corresponding specific type shall not have a primitive procedure to which
+ a pragma Implemented applies unless the implementation_kind of the pragma is
+ By_Any;
-Add four new paragraphs after E.2.2(18):
+Add two 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.
-
- 8 Remote access types allow no more than the interface of an object to be accessed
- remotely. A remote access-to-class-wide limited interface type can be used anywhere
- other remote access-to-class-wide types can be used, and better represents the
- remote access capability that is being allowed. Therefore it is recommended that
- remote access-to-class-wide types be used to designate class-wide limited
- interface types rather than other class-wide limited types.
-
- 9 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.
+ 6 The value of a remote access-to-class-wide limited interface can designate
+ an object of a nonlimited type derived from the interface.
+ 7 A remote access type may designate a class-wide synchronized, protected,
+ or task interface type.
+
!discussion
Ada 2005 introduces interfaces and expanded usage of anonymous access types
@@ -150,17 +121,20 @@
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
+library units. AI05-0084-1 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
+to have to redesign the corresponding library_unit_body in many cases. Moreover,
+1.1.3(17) requires an implementation to reject (or raise an exception) for
+the use of unsupported Annex features, and we surely want all Ada compilers
+to be able to compile language-defined units. 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 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
@@ -215,26 +189,26 @@
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.
+required to be implemented by protected subprograms, since protected subprograms
+are not supposed to be potentially blocking operations. Synchronized interfaces
+could be used, however, where the primitive subprograms are "normal" as normal
+subprograms can contain potentially blocking operations (including calls on
+entries and protected subprograms). Normal primitive subprograms can even
+be implemented directly as entries or protected subprograms, as these are
+logicially a wrapper that makes the necessary call from a normal subprogram,
+and thus also can be potentially blocking.
-On the surface, being able to call task entries and protected entries remotely seems
+On the surface, being able to call task 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.
+difficult to implement. Such a capability might be worth considering in the
+the future. However, for now, we disallow remote access types of limited
+interface types where one or more primitive subprograms are required (by
+pragma Implemented, see AI05-0030-2) to be 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
@@ -255,16 +229,71 @@
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.
+
+!corrigendum A(4)
-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 since typically there are
-synchronization needs associated with remote access type usage.
+@dinsa
+The implementation may restrict the replacement of language-defined compilation units.
+The implementation may restrict children of language-defined library units (other
+than Standard).
+@dinst
+An implementation may omit pragma Remote_Types (see E.2.2) in language-defined
+library units if the implementation does not conform to Annex E.
+
+!corrigendum E.2.2(9/1)
+
+@drepl
+An access type declared in the visible part of a remote types or
+remote call interface library unit is called a @i<remote access type>.
+Such a type shall be:
+@dby
+A named access type declared in the visible part of a remote types or
+remote call interface library unit is called a @i<remote access type>.
+Such a type shall be:
+
+!corrigendum E.2.2(9.2/1)
+
+@drepl
+@xbullet<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.>
+@dby
+@xbullet<a general access type that designates a class-wide limited private type,
+a class-wide limited interface type, or a class-wide private extension
+all of whose ancestors are either private extensions, limited interface types,
+or limited private types.>
+
+!corrigendum E.2.2(14/2)
+
+@drepl
+@xbullet<The primitive subprograms of the corresponding specific limited private
+type shall only have access parameters if they are controlling formal
+parameters; each non-controlling formal parameter shall support external
+streaming (see 13.13/2);>
+@dby
+@xbullet<The primitive subprograms of the corresponding specific
+type shall only have access parameters if they are controlling formal
+parameters; each non-controlling formal parameter shall support external
+streaming (see 13.13/2);>
+
+@xbullet<The corresponding specific type shall not have a primitive procedure to which
+a @fa<pragma> Implemented applies unless the @fa<implementation_kind> of the pragma is
+By_Any;>
+
+!corrigendum E.2.2(18)
+
+@dinsa
+A remote types library unit need not be pure, and the types it defines may include
+levels of indirection implemented by using access types. User-specified Read and
+Write attributes (see 13.13.2) provide for sending values of such a type between
+active partitions, with Write marshalling the representation, and Read unmarshalling
+any levels of indirection.
+@dinss
+The value of a remote access-to-class-wide limited interface can designate
+an object of a nonlimited type derived from the interface.
---
+A remote access type may designate a class-wide synchronized, protected,
+or task interface type.
!ACATS Test
Questions? Ask the ACAA Technical Agent