CVS difference for ais/ai-00254.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00254.txt

--- ais/ai-00254.txt	2002/12/04 23:43:38	1.5
+++ ais/ai-00254.txt	2003/09/24 20:50:34	1.6
@@ -1,4 +1,4 @@
-!standard 03.10   (11)                               02-02-25  AI95-00254/03
+!standard 03.10   (11)                               03-09-22  AI95-00254/04
 !class amendment 00-12-06
 !status work item 02-11-06
 !status ARG Approved 5-0-2  02-02-11
@@ -10,31 +10,36 @@
 
 !summary
 
-Access-to-subprogram parameters are introduced which enable an access to a
-subprogram at any level to be passed as an actual parameter.
+Access parameters are extended to include anonymous access-to-subprogram
+types. These enable an access to a subprogram at any level to be passed as
+an actual parameter.
 
 !problem
 
 Despite the improvements introduced in Ada 95, there is no still no
 convenient way to perform certain general operations such as integration,
-minimization, iteration etc where the operation has to be parameterized by
+minimization, iteration etc. where the operation has to be parameterized by
 a subprogram. This functionality was provided in Algol 60 and Pascal and it
 is surprising that it is not in Ada.
 
 !proposal
 
-Access-to-subprogram parameters are introduced as a further form of
-subprogram parameter. The changes to the syntax are as follows
+Access parameters are extended to include anonymous access-to-subprogram types.
+The changes to the syntax are as follows
 
-   parameter_specification ::=
-        defining_identifier_list: mode subtype_mark [:= default_expression]
-      | defining_identifier_list: access_definition [:= default_expression]
-      | defining_identifier_list: access_to_subprogram_definition
-                                                    [:= default_expression]
-
-The actual subprogram must be an access value designating a subprogram
-which is subtype conformant to the formal profile. The actual parameter
-must not be null (this is a runtime check).
+[NOTE: this assumes that AI-231 is approved and is based on version 04; if the
+changes approved to AI-231/04 by straw votes at Toulouse are confirmed then
+the syntax will need modifying to move not_null_constraint.]
+
+   access_definition ::=
+      access [all | constant] subtype mark [not_null_constraint] |
+      access procedure parameter_profile [not_null_constraint] |
+      access function parameter_and_result_profile [not_null_constraint]
+
+The actual subprogram corresponding to an anonymous access-to-subprogram
+parameter must be an access value designating a subprogram which is subtype
+conformant to the formal profile. If a not_null_constraint is supplied then
+the actual parameter must not be null (this is a runtime check).
 
 The only operations permitted on such a formal subprogram parameter are a)
 to call it, and b) to pass it as an actual parameter to another subprogram
@@ -42,10 +47,11 @@
 parallels the functionality of the corresponding construction in languages
 such as Pascal.)
 
-Type conversions on such parameters are forbidden and since they are of
-anonymous type like access-to-object parameters this implies that
-assignment of them is forbidden. The accessibility level of such parameters
-is considered to be infinite and this prevents the writing of P.all'Access
+The accessibility level of such parameters is considered to be infinite.
+This prevents all explicit type conversions on such parameters. Moreover,
+since they are of anonymous type like access-to-object parameters this
+implies that assignment of them is forbidden. Note that the infinite
+accessibility level also prevents the writing of P.all'Access
 which could otherwise create a hidden type conversion. (These restrictions
 again avoid a number of potential implementation difficulties.)
 
@@ -59,11 +65,95 @@
 parameters.
 
 Default parameters are permitted for access-to-subprogram parameters with
-the semantics of renaming. The default must not be null.
+the usual semantics for parameters of mode in.
 
 The convention of an access-to-subprogram parameter is the convention of the
-subprogram that contains the parameter.
+subprogram that contains the parameter. It cannot be changed by a pragma
+such as Convention.
+!wording
 
+Replace the second sentence of 3.7(9) by
+
+A discriminant that is defined by an access_definition is called an
+access_discriminant. The access definition shall designate an access-to-object
+type. The access disriminant is of an anonymous general access-to-object type
+whose designated subtype is denoted by the subtype_mark of the
+access_definition.
+
+[NOTE: this prevents access-to-subprogram types as access discriminants.]
+
+Replace 3.10(6) by
+
+   access_definition ::=
+      access [all | constant] subtype mark [not_null_constraint] |
+      access procedure parameter_profile [not_null_constraint] |
+      access function parameter_and_result_profile [not_null_constraint]
+
+[NOTE: this assumes AI-231/04 and will need modifying to conform to the
+final version of that AI.]
+
+
+Replace 3.10(12) by
+
+An access_definition defines an anonymous general access type or an
+anonymous access-to-subprogram type. For a general access type, the subtype
+mark denotes its designated subtype; if the word constant appears,
+the type is an access-to-constant type; otherwise it is an
+access-to-variable type. For an access-to-subprogram type, the
+parameter_profile or parameter_and_result_profile denotes its designated
+profile.
+
+If a not_null_constraint is present, or the
+access_definition is for a controlling access parameter (see 3.9.2), the
+access_definition defines an access subtype which excludes the null value;
+otherwise the subtype includes a null value. An access_definition is used
+in the specification of an access discriminant (see 3.7) or an access
+parameter (see 6.1). [NOTE: Modify this last sentence if AI-230 is approved.]
+
+Replace 3.10.2(13) by
+
+*   The accessibility level of the anonymous access type of an access
+    parameter specifiying an access-to-object type is the same as that
+    of the view designated by the actual. If the actual is an allocator,
+    this is the accessibility level of the execution of the called subprogram.
+
+*   The accessibility level of the anonymous access type of an access parameter
+    specifiying an access-to-subprogram type is infinite.
+
+[NOTE: I don't think anything else in this section needs changing. In
+particular, 3.10.2(32) seems OK still.]
+
+Replace 6.1(24) by
+
+An access parameter is a formal in parameter specified by an access_definition.
+An access parameter is of an anonymous general access-to-object type or an
+aononymous access-to-subprogram type (see 3.10). Access parameters of an
+access-to-object type allow dispatching calls to be controlled by access
+values. Access parameters of an access-to-subprogram type permit calls to
+subprograms passed as parameters irrespective of their accessibility level
+(commonly called downward closures).
+
+Replace 6.1(27) by
+
+*   For access parameters of an access-to-object type, the designated
+    subtype of the the parameter type.
+
+*   For access parameters of an access-to-subprogram type, the subtypes of
+    the profile of the parameter type.
+
+Add after 6.3.1(13)
+
+*   The calling convention for an access parameter of an access-to-subprogram
+    type is the convention of the subprogram that contains the parameter. It
+    shall not be overridden. [NOTE: despite 6.3.1(3)]
+
+[NOTE: 6.4.1(6) says
+
+The type of the actual parameter associated with an access parameter shall be
+convertible (see 4.6) to its anonymous access type.
+
+This seems to cover both cases and so doesn't need changing.]
+
 !discussion
 
 There are two basic uses for what might loosely be called pointers to
@@ -77,8 +167,8 @@
 The first usage was familiar in older languages such as Algol and Pascal.
 The second usage was provided in newer languages such as C and Modula. Ada
 83 was unhelpful in both areas and workarounds had to be used. Ada 95
-solved the callback problem through the introduction of general access-to-
-object types. However, the functional parameterization problem in its
+solved the callback problem through the introduction of named access-to-
+subprogram types. However, the functional parameterization problem in its
 general form still remains.
 
 LSN 1083, a condensed version of which is at the end of this discussion
@@ -176,7 +266,7 @@
 Addressing these three reasons: a) the proposal given here disallows all
 assignment of access-to-subprogram parameters thereby greatly reducing the
 implementation burden, b) the workarounds are horrid and a continual
-embarrassment in a general purpose language , c) seemingly much bigger
+embarrassment in a general purpose language, c) seemingly much bigger
 changes are being formulated for Ada 0y and it would not seem that much of
 a change to users but a relief.
 
@@ -712,7 +802,7 @@
 !reference RM9X-3.10.2(16);4.0
 !reference AARM-12.3(12.p,12.q);4.0
 !reference LSN-1042 on Accessibility Checks in Generics
-!from Bob Duff $Date: 2002/12/04 23:43:38 $ $Revision: 1.5 $
+!from Bob Duff $Date: 2003/09/24 20:50:34 $ $Revision: 1.6 $
 !discussion
 
 Two issues related to access types and the accessibility rules came
@@ -1125,7 +1215,7 @@
 !topic LSN on Accessibility Checks in Generics
 !key LSN-1042 on Accessibility Checks in Generics
 !reference MS-12;4.6
-!from Bob Duff $Date: 2002/12/04 23:43:38 $ $Revision: 1.5 $
+!from Bob Duff $Date: 2003/09/24 20:50:34 $ $Revision: 1.6 $
 !discussion
 
 This Language Study Note discusses accessibility checks, and their

Questions? Ask the ACAA Technical Agent