CVS difference for ai05s/ai05-0060-1.txt
--- ai05s/ai05-0060-1.txt 2008/05/10 05:14:33 1.9
+++ ai05s/ai05-0060-1.txt 2008/05/29 04:36:46 1.10
@@ -1,4 +1,4 @@
-!standard A(4) 08-04-09 AI05-0060-1/06
+!standard A(4) 08-05-21 AI05-0060-1/07
!standard E.2.2(9/1)
!standard E.2.2(9.2/1)
!standard E.2.2(14/2)
@@ -14,9 +14,9 @@
!summary
-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 RM should formally state implementations may omit pragma Remote_Types
+in standard library library_unit_declarations if the implementation
+does not conform to Annex E.
The definition of remote access types is clarified to apply only to
named access types.
@@ -29,40 +29,42 @@
!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? (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,
-should we allow the value of a remote access-to-class-wide limited interface type to
-designate a nonlimited object? (Yes.)
+(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 remote
+access type is allowed to designated a class-wide limited private 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,
+should we allow the value of a remote access-to-class-wide limited interface
+type to designate a nonlimited object? (Yes.)
+
+(3) E.2.2(16/1) states that remote access types cannot be dereferenced except
+through dispatching calls. This would be the rule that would allow the value of
+a remote access-to-class-wide limited interface type to be an object of a
+nonlimited type. 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? (No.)
+
+(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 rule makes significant restrictions on
+which anonymous access types can be used and how.
+
+For instance, an access-to-subprogram parameter is required by this rule to be
+passed only remote subprograms, even though the subprogram that is using the
+parameter is not itself a remote subprogram.
-(3) E.2.2(16/1) states that remote access types cannot be dereferenced except through
-dispatching calls. This would be the rule that would allow the value of a remote
-access-to-class-wide limited interface type to be an object of a nonlimited type.
-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? (No.)
-
-(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
-rule makes significant restrictions on which anonymous access types can be used and how.
-
-For instance, an access-to-subprogram parameter is required by this rule to be passed
-only remote subprograms, even though the subprogram that is using the parameter is not
-itself a remote subprogram.
-
Should this restriction be relaxed? (Yes.)
-(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.
+(5) Should we formally say that Remote_Types 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.
!recommendation
@@ -72,13 +74,14 @@
Add a new paragraph after A(4):
- 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.
+ 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:
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.
+ remote call interface library unit is called a remote access type.
Such a type shall be:
@@ -95,14 +98,14 @@
* 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);
+ streaming (see 13.13.2);
-Add a new paragraph after E.2.2(14/2): [Note: This depends on pragma Implemented,
-which was added by AI05-0030-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 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;
+ * 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 two new paragraphs after E.2.2(18):
@@ -117,125 +120,125 @@
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.
+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-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. 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 Annex E restrictions.
+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. 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 omit the Remote_Types
+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
+Remote_Types restrictions.
-The main focus of this AI is to clarify the definition of remote types and remote
-access types.
+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 designate only private tagged types that are limited in nature whereby all
-components of the type are private.
+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
+type. If remote access types are allowed to designate class-wide limited
+interface types, then 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 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 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.
+remote (client) 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 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.
Since we are now saying that a remote access type can designate a nonlimited
object, we need to ask whether it makes sense for remote access types to
designate class-wide nonlimited private types and nonlimited interface types, or
even more generally, any class-wide types. It seems like this could be workable,
-so long as the E.2.2(16/1) rule is upheld. This rule would ensure that the
+so long as the E.2.2(16/1) rule is upheld. This rule would ensure that the
object designated by the remote access type can only be accessed as though it
were limited and private. That is, the object could not be assigned and its
components cannot be directly accessed remotely.
-Such a change would be a bigger change to the language however, and there are
-no known use cases that demonstrate a need for this capability that could not
-be covered by using a remote access-to-class-wide limited interface type.
+Such a change would be a bigger change to the language however, and there are no
+known use cases that demonstrate a need for this capability that could not be
+covered by using a remote access-to-class-wide limited interface type.
Therefore, it has been concluded that the restrictions for remote access types
should not be relaxed any further than to just allow remote access-to-class-wide
limited interface types.
-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
-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.
+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 remote access
+types can designate such interface 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 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 and protected entries remotely seems
-to be a powerful construct. Furthermore, such a language feature might allow the
+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 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
-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.
+this time that implementing remote requeue and remote entry calls would be quite
+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 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.
!corrigendum A(4)
@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).
+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.
@@ -244,11 +247,11 @@
@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>.
+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>.
+remote call interface library unit is called a @i<remote access type>.
Such a type shall be:
!corrigendum E.2.2(9.2/1)
@@ -276,18 +279,18 @@
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;>
+@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.
+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.
@@ -305,45 +308,45 @@
From: Brad Moore
Sent: Tuesday, June 19, 2007 2:29 AM
-I have come across a potential use for interface types that currently is not allowed in Ada 2005,
-yet seems like it would be a useful and natural extension to add to the language.
-At the very least, it seems worthy of discussion. It seems that this capability could be enabled
-by making only minor wording changes to Annex E to relax restrictions for remote access types.
+I have come across a potential use for interface types that currently is not allowed in Ada 2005,
+yet seems like it would be a useful and natural extension to add to the language.
+At the very least, it seems worthy of discussion. It seems that this capability could be enabled
+by making only minor wording changes to Annex E to relax restrictions for remote access types.
Specifically, it seems useful to be able to specify limited interfaces as remote access types.
-
+
However E.2.2(9/1) states:
-
-(9/1) An access type declared in the visible part of a remote types or remote call interface library unit is called
+
+(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
-
+
(9.1/1) - an access-to-subprogram type, or
-(9.2/1) - a general access type that designates a class-wide limited private type or a class-wide private type extension
+(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.
-
-
+
+
A limited interface cannot be used because of the restriction in (9.2/1) since an interface
is not a private type, even though it would seem to be implicitly private since an
-interface type cannot have any visible record components.
-
+interface type cannot have any visible record components.
+
eg. The following code excerpt will compile if Client_Buffer_Type is declared as
an abstract tagged limited private type. It does not compile if it declared as
a limited interface type, due to the restriction stated in (9.2/1) above.
-
+
package Buffer_Notifications is
pragma Pure;
-- type Client_Buffer_Type is abstract tagged limited private;
type Client_Buffer_Type is limited interface;
-
+
procedure Notify
(Buffer_Client : access Client_Buffer_Type;
Data : in String) is abstract;
-
+
--private
-- type Client_Buffer_Type is abstract tagged limited null record;
end Buffer_Notifications;
-
+
with Buffer_Notifications; use Buffer_Notifications;
package Buffer_Server is
pragma Remote_Call_Interface;
@@ -351,42 +354,42 @@
procedure Register (Buffer : Buffer_Access);
procedure Send_To_Buffers(Data : String);
No_More_IDs : exception;
-
+
end Buffer_Server;
-
+
It seems this could be allowed if E.2.2(9.2/1) were modified from;
-
+
(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."
-
+
to state;
-
+
(9.2/1) "a general access type that designates a class-wide limited interface type or
a class-wide limited private type or a class-wide private type extension all of
whose ancestors are private type extensions, interface types, or limited private types"
-
+
Also E.2.2(14/2) would likely need to be modified from;
-
-"The primitive subprograms of the corresponding specific limited private type shall only have
+
+"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);"
-
-to something along the lines;
-
+
+to something along the lines;
+
"The primitive subprograms of the corresponding specific limited private type or
limited interface 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);"
-
+
Hopefully the following questions could be considered in the discussion that might
be generated;
-
+
Would this be a change that would be relatively easy for vendors to implement?
Is there a general feeling that this would be a useful capability?
Are there reasons why limited interface types are restricted from being remote access types?
Should an AI be created for this?
-
+
****************************************************************
From: Tucker Taft
@@ -406,38 +409,38 @@
From: Brad Moore
Sent: Wednesday, June 20, 2007 11:45 AM
-Thanks Tuck, for sharing your niggling concern. I share your concern,
+Thanks Tuck, for sharing your niggling concern. I share your concern,
so I have revised my suggested wording changes, because it seems that
the wording I originally suggested allows a private extention that is
derived from a nonlimited interface.
-
-Also, just to clarify, the intent of my suggested revision to
-the wording is to not only allow class-wide limited interfaces
-as remote access types, but to also allow class-wide
-synchronized interfaces, class-wide protected interfaces,
-and class-wide task interfaces as remote access types.
-Since all of these are limited, I am hoping the wording is
+
+Also, just to clarify, the intent of my suggested revision to
+the wording is to not only allow class-wide limited interfaces
+as remote access types, but to also allow class-wide
+synchronized interfaces, class-wide protected interfaces,
+and class-wide task interfaces as remote access types.
+Since all of these are limited, I am hoping the wording is
generic enough to include those others as well.
-
+
Firstly,
-
+
RM 7.3(6/2) defines the notion of a limited private extension,
-
+
7.3(6/2) "A private type is limited if its declaration includes the reserved
word limited; a private extension is limited if its ancestor type is a
-limited type that is not an interface type,
-or if the reserved word limited or synchronized appears in its definition.
-If the partial view is nonlimited, then the full view shall be nonlimited.
-If a tagged partial view is limited, then the full view shall be limited.
+limited type that is not an interface type,
+or if the reserved word limited or synchronized appears in its definition.
+If the partial view is nonlimited, then the full view shall be nonlimited.
+If a tagged partial view is limited, then the full view shall be limited.
On the other hand, if an untagged partial view is limited, the full view
may be limited or nonlimited."
-
+
Also relevant is;
- 7.3 (8.1/2) "If the reserved word limited appears in a private_extension_declaration,
-the ancestor type shall be a limited type. If the reserved word synchronized appears
+ 7.3 (8.1/2) "If the reserved word limited appears in a private_extension_declaration,
+the ancestor type shall be a limited type. If the reserved word synchronized appears
in a private_extension_declaration, the ancestor type shall be a limited interface."
-
-It seems to help the wording if we speak of limited private extensions, rather than
+
+It seems to help the wording if we speak of limited private extensions, rather than
just private extensions, so I inserted "limited" before "private extension" in my
revised suggested wording. Also, the RM defines "private extension", but does not
define "private type extension", so I removed the word "type".
@@ -445,26 +448,26 @@
"private type extension" only appears in this one paragraph. I presume that there
might be value in making this minor editorial change regardless of whether any other
wording changes are made to 9.2/1.
-
-
+
+
New suggested wording for E.2.2 (9.2/1);
-
+
E.2.2 (9.2/1) "a general access type that designates a class-wide limited interface type
or a class-wide limited private type or a class-wide limited private extension."
-
+
The phrase "all of whose ancestors are private type extensions, interface types, or
limited private types" seems redundant to me. If the private extension is limited,
all ancestor private type extensions and private types would also have to be limited.
Is that correct? That is why I also removed that clause. The sentence is now simpler,
but hopefully I haven't removed something that was needed.
-
+
I would appreciate any feedback if anyone sees any problems or holes in the proposed
wording. I realize I am probably getting ahead of myself with proposed wording changes,
I am hoping only to suggest that any such wording changes needed for this change would
likely be minimal. More important at this time, would be to get a sense for how others
felt about the usefulness or need for being able to use class-wide limited interface
types as remote access types.
-
+
****************************************************************
From: Tucker Taft
@@ -497,20 +500,20 @@
>
> because we want to rule out the case where a private extension
> has a non-private record or record extension as an
-> ancestor.
-
+> ancestor.
+
Of course you are right. I was focussing too much on the limitedness
-factor, at the expense of the privateness factor.
-
+factor, at the expense of the privateness factor.
+
Also, I now think it is better to move the word "limited" from where I
-originally suggested, before "private extension all of whose ancestors..."
+originally suggested, before "private extension all of whose ancestors..."
to before "interface types" in the clause that we cannot remove.
-
+
ie.,
-
-E.2.2 (9.2/1) "a general access type that designates a class-wide limited
+
+E.2.2 (9.2/1) "a general access type that designates a class-wide limited
interface type or a class-wide limited private type or a class-wide private
-extension all of whose ancestors are private extensions,
+extension all of whose ancestors are private extensions,
limited interface types, or limited private types."
That seems to more neatly plug the hole in the wording I originally suggested that
@@ -523,34 +526,34 @@
> any problem with that, but it is something new.
That is something I hadn't thought of and didn't pick up
-from your original reply. I see that now. I also think I see why it's not
+from your original reply. I see that now. I also think I see why it's not
easy to know offhand if there is an issue with this or not. It seems quite likely
that there wouldn't be an issue, but requires some more deeper thought
-to think it through.
-
+to think it through.
+
On the surface this limitedness issue seems to be a similar issue
to the corresponding privateness issue. That is, I believe it is possible to
extend a private extension with a record extension, so that the
*object* used in a remote access type could have visible components.
-
+
I believe non-private object components would have been allowed in remote
-access type objects in Ada 95 also, and that part does not seem to have changed,
+access type objects in Ada 95 also, and that part does not seem to have changed,
so if it wasn't a problem in Ada95, it likely isn't a problem in Ada 2005 either.
-
-The new thing as a result of this suggested change would be that an object used
+
+The new thing as a result of this suggested change would be that an object used
as a class-wide remote access type could now be non-limited, in addition to possibly
containing non-private components.
-
+
The remote "view" of these objects would be that of a limited private type, but the local
"view" could be not as restrictive. The ramification of this would mean that locally,
-the object could be copied, or assigned to.
-
+the object could be copied, or assigned to.
+
At this point, I don't see a problem with this, but cannot say for sure that there
wouldn't be a problem with this either, or if there may be other issues that I
may have overlooked.
-
+
Hmmmmm.
-
+
Any thoughts anyone might have on this are appreciated.
****************************************************************
@@ -645,10 +648,10 @@
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.
Also, this would seem to rule out functions since those are not supposed
-to be potentially blocking.
+to be potentially blocking.
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.
+the protected object which would be remote.
Here are some relevant excerpts from private emails on this topic.
@@ -660,7 +663,7 @@
Brad Moore wrote:
-> I am investigating AI05-0060. Do you think that Synchronized
+> I am investigating AI05-0060. Do you think that Synchronized
> interfaces should be allowed as remote types?
Protected types were designed with tightly coupled, shared memory
@@ -669,7 +672,7 @@
difficult to define the semantics of distributed entry and protected subprogram
calls, and it would no doubt be quite difficult to implement.
-> synchronized capabilities considered farther in the future,
+> synchronized capabilities considered farther in the future,
> maybe Ada 2015?
Well, that's up to ARG, but I doubt synchronized remote types would fly.
@@ -693,7 +696,7 @@
> The overall sense so far is that this would not fly, due to difficulties
> in defining semantics and implementing those semantics, but it would be
> interesting to see what others thought.
-
+
Hmm.. Thinking about it... What about a remote requeue?
****************************************************************
@@ -735,10 +738,10 @@
-- task type that implements Remote_Task.
> 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.
@@ -753,14 +756,14 @@
directly as a protected subprogram.
> Also, this would seem to rule out functions since those are not supposed
-> to be potentially blocking.
+> to be potentially blocking.
Only if they are implemented directly as a protected subprogram.
Not if they are implemented as a "normal" subprogram.
> 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.
+> 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.
@@ -851,7 +854,7 @@
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.
+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,
@@ -878,44 +881,44 @@
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
+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
+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
@@ -947,12 +950,12 @@
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
@@ -972,17 +975,17 @@
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
+
+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
@@ -996,15 +999,15 @@
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);
-
+ 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
@@ -1057,7 +1060,7 @@
> * 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);
+> 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
@@ -1087,18 +1090,18 @@
> 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".
-
-You are right. I misread the sentence to mean any access parameter type,
-including named and anonymous access types. To get the meaning I was
-thinking of, I believe the sentence would have had to have specifed
-"access type parameters" instead of "access parameters".
+
+You are right. I misread the sentence to mean any access parameter type,
+including named and anonymous access types. To get the meaning I was
+thinking of, I believe the sentence would have had to have specifed
+"access type parameters" instead of "access parameters".
That is pretty subtle. I wonder if it would be helpful in the AARM HTML
version if references to "access parameter"s could be hyperlinked to where
the term is defined. That might have avoided the confusion in my case.
-
-The added clause, "or remote type parameters" above should be removed from
+
+The added clause, "or remote type parameters" above should be removed from
the proposed wording changes. I have removed my added question and related text
-from AI05-0060.
+from AI05-0060.
> I suppose you could allow anonymous access types to *be* remote access types
> in very limited circumstances (presumably only for access-to-classwide), but
@@ -1109,7 +1112,7 @@
I tend to agree. It seems cleaner and simpler to just say that remote access
types must be named access types.
-
+
****************************************************************
From: Brad Moore
@@ -1122,15 +1125,15 @@
workable, so long as the E.2.2 16/1 rule is upheld. This rule would ensure that
the object designated by the remote access type can only be accessed as though
it were limited and private. That is, the object could not be assigned and its
-components cannot be directly accessed remotely.
+components cannot be directly accessed remotely.
E.2.2(16/1) states that remote access types cannot be dereferenced except through
dispatching calls. This would be the rule that would allow the value of a remote
access-to-class-wide limited interface type to be an object of a nonlimited type.
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?
+is limited and private in nature, should we allow remote access types to designate
+all class-wide types?
****************************************************************
@@ -1148,7 +1151,7 @@
Sent: Friday, February 1, 2008 2:44 PM
That was my thought as well, which is why my current wording that
-I submitted to Randy earlier today suggests that though this is a
+I submitted to Randy earlier today suggests that though this is a
possibility, it should be dealt with in a separate AI, if at all.
The approach taken in AI05-0060 is to get maximum capability with
minimal wording changes. (Best bang for the buck)
@@ -1178,29 +1181,29 @@
Sent: Saturday, February 2, 2008 6:37 PM
> I think Tuck's point was that you could add a limited interface to such a
-> non-limited type without doing any other changes to the type.
-
-Good point. I agree. I do not see any use cases that could not be covered by using a
+> non-limited type without doing any other changes to the type.
+
+Good point. I agree. I do not see any use cases that could not be covered by using a
remote access to limited interface type.
-
+
> Indeed, if we were doing this from scratch, it would make sense to allow
> *only* limited interfaces in this case, because they're really what is being implemented
-> remotely (an interface, nothing more).
-
- This raises another question.
-
+> remotely (an interface, nothing more).
+
+ This raises another question.
+
If we want to recommend that remote access-to-class-wide types should designate
limited interface types in Ada 2005, should we change the wording so that
previously allowed remote access to class-wide limited private types or
class-wide private extensions are obsolescent features described in Annex J?
-
+
If we want to recommend the use of limited interface types, this might make it clearer
that the previous uses should no longer be needed in Ada 2005
-
+
Regardless whether Annex J is involved, I think it probably makes sense that
a note be added to Annex E to recommend limited interface types over other
remote access-to-class-wide types for Ada 2005.
-
+
I will assume that if changes should be made to Annex J, that those would be
best covered in a separate AI, unless I hear otherwise.
Questions? Ask the ACAA Technical Agent