CVS difference for ai12s/ai12-0220-1.txt
--- ai12s/ai12-0220-1.txt 2017/04/21 05:43:53 1.2
+++ ai12s/ai12-0220-1.txt 2017/06/10 04:24:23 1.3
@@ -1,4 +1,4 @@
-!standard 6.1.1(1/4) 17-04-07 AI12-0220-1/01
+!standard 6.1.1(1/4) 17-06-09 AI12-0220-1/02
!standard 6.1.1(39/3)
!class Amendment 17-04-07
!status work item 17-04-07
@@ -20,13 +20,87 @@
!wording
-** Assigned to Steve Baird
+6.1.1
+
+In 1/4, "For a noninstance subprogram, a generic subprogram, or an entry"
+becomes "For a noninstance subprogram, a generic subprogram, an entry, or
+an access-to-subprogram type".
+
+In 2/3 and 4/3, "for a callable entity" becomes "for a callable entity
+or an access-to-subprogram type".
+
+Intent: Pre and Post aspects may be specified for access-to-subprogram types.
+
+In 28/3 "that denotes a function declaration" becomes "that denotes a
+ function declaration or an access-to-function type (that is, an
+ access-to-subprogram type whose designated profile is a function profile)".
+
+In 29/3, "Within a postcondition expression for function F" becomes
+"Within a postcondition expression".
+
+Intent: 'Result works for access-to-subp postconditions.
+
+
+Replace 39/3 with:
+ For a call via an access-to-subprogram value, precondition and
+ postcondition checks performed are as determined by the subprogram or entry
+ denoted by the prefix of the Access attribute reference that produced the
+ value. In addition, before any such precondition checks are performed,
+ any precondition associated with the access-to-subprogram type is checked
+ Similarly, after any such postcondition checks are performed, any
+ postcondition associated with the access-to-subprogram type is checked.
+ More specifically, a call via an access-to-subprogram value is
+ equivalent (with respect to dynamic semantics) to call to a notional
+ "wrapper" subprogram which has the Pre and Post aspects and the profile of the
+ access-to-subprogram type and whose body contains (and returns, in the case
+ of a function) only a call to the designated subprogram. [This equivalence,
+ determines, for example, the point at which the constant associated with
+ an Old attribute reference in the Post aspect for an access-to-subprogram
+ type is elaborated and finalized. Note that in the case of type conversion
+ between two access-to-subprogram types, the Pre and Post aspects of the
+ source type of the conversion play no role in any subsequent call via
+ the conversion result; only the Pre and Post aspects of the target type
+ of the conversion are relevant in that case. The same applies in the
+ case of a "conversion" (using the term loosely) which is accomplished by
+ combining a dereference and a 'Access attribute reference, as in
+ Some_Pointer.all'Access.]
+
+Intent: This is the heart of the matter - the dynamics semantics of a
+ call to Ptr.all where Pre/Post has been specified for Ptr's type.
+
+Question: Is this overspecified? Do we want an implementation permission
+ here allowing the Pre/Post checks of the access-to-subprogram type
+ to be interspersed with those of the designated subprogram?
+
+====
+
+13.1.1
+
+In 12/5. "If the associated declaration is for a subprogram or entry, the
+names of the formal parameters are directly visible" becomes "If the associated
+declaration is for a subprogram, an entry, or an access-to-subprogram type,
+the names of the formal parameters are directly visible".
+
+Intent: In Pre/Post for an access-to-subp, ok to mention parameters,
+'Result and 'Old.
+
+Question: Could this possibly introduce an incompatibility? If so,
+ then do we want to restrict this rule (in the new access-to-subprogram case)
+ to apply only in the case of a Pre or Post aspect specification.
+
+A more restrictive version of this rule might be to leave sentence
+in 12/5 unmodified and instead append something like
+ "Formal parameter names are similarly directly visible in
+ a Pre or Post aspect specification for an access-to-subprogram type".
+immeditely afterwards.
+
+
-Notes: The basic idea only needs modifying 6.1.1(1/4) to allow Pre/Post on
-access-to-subprogram types, and 6.1.1(39/3) to say that Pre/Post of the
-access type is also evaluated.
+!discussion
+
+** Assigned to Steve Baird
-We also need to consider doing the same for formal subprograms (important)
+We also need to consider allowing Pre/Post for formal subprograms (important)
and for renames (not important, other than to be consistent with formal
subprograms).
@@ -38,9 +112,7 @@
This latter issue may be better split to a separate-but-related AI; I'll
leave that to Mr. Baird.
-!discussion
-
-** Assigned to Steve Baird
+---
We definitely need to explain here why we're not making any attempt at
matching. It seems to me that is a job for separate tools (and style rules??),
@@ -645,11 +717,11 @@
From: Randy Brukardt
Sent: Friday, April 7, 2017 10:13 PM
-> (1) Allow a separate declaration for closure access types, so that
-> we can give properties of the type as needed (contracts in particular,
-> but also possibly conventions, alignment, or anything else that can
+> (1) Allow a separate declaration for closure access types, so that
+> we can give properties of the type as needed (contracts in particular,
+> but also possibly conventions, alignment, or anything else that can
> get defined by an aspect);
-> (2) Allow giving a name for closure access types, so one does not
+> (2) Allow giving a name for closure access types, so one does not
> have to repeat a given profile in many subprogram declarations;
> (3) Allow closure access types in more contexts (local objects?
> components? etc.);
@@ -778,10 +850,10 @@
From: Erhard Ploedereder
Sent: Friday, April 14, 2017 12:55 PM
-> A more radical idea is to get rid of "access" completely and talk
-> about "subprogram types." Bob Duff pushed a bit for that originally,
-> and it should probably be on the table. These would of course be of a
-> limited type again. This is somewhat related to lambda expressions,
+> A more radical idea is to get rid of "access" completely and talk
+> about "subprogram types." Bob Duff pushed a bit for that originally,
+> and it should probably be on the table. These would of course be of a
+> limited type again. This is somewhat related to lambda expressions,
> aka function expressions.
In the end, I think this is much preferable to subprogram access types (even
@@ -828,14 +900,14 @@
From: Bob Duff
Sent: Friday, April 14, 2017 4:27 PM
-> I agree "access" is noise, but not necessarily the "not null". Because
+> I agree "access" is noise, but not necessarily the "not null". Because
> I often use:
->
+>
> procedure P (...; Logger : access procedure (Msg : String) := null);
->
-> to provide an optional debugging log. This is the best way (IMHO) to
-> add debugging to Pure and Preelaborated packages (in the latter case,
-> Ada 2012 has another option, but for code portable to non-GNAT
+>
+> to provide an optional debugging log. This is the best way (IMHO) to
+> add debugging to Pure and Preelaborated packages (in the latter case,
+> Ada 2012 has another option, but for code portable to non-GNAT
> compilers the above is best).
I never do that. I don't want to scatter "if Logger /= null..."
@@ -843,14 +915,14 @@
that does nothing, then write a procedure that does nothing. Plus null might
mean something else (e.g. "send the logs to a default location").
->... There is no logging if the subprogram is null (this is often the
+>... There is no logging if the subprogram is null (this is often the
>normal case).
For logging, yes. But it's not often you want a do-nothing default for
anon-access-to-subp params.
-> Without the null, one has to use a dummy routine and that could be
-> substantially more expensive (calls dumping pipelines on modern
+> Without the null, one has to use a dummy routine and that could be
+> substantially more expensive (calls dumping pipelines on modern
> machines) and surely clutters the code
Clutters the code less than "if Logger /= null".
@@ -871,7 +943,7 @@
From: Bob Duff
Sent: Friday, April 14, 2017 4:48 PM
-> For logging, yes. But it's not often you want a do-nothing default
+> For logging, yes. But it's not often you want a do-nothing default
> for anon-access-to-subp params.
FWIW, in the gnat sources, I see about 230 anon-access-to-subp params.
@@ -901,7 +973,7 @@
Sent: Friday, April 14, 2017 5:22 PM
> I never do that. I don't want to scatter "if Logger /= null..."
-> all over the place. Plus it just seems kludgy -- if you want a
+> all over the place. Plus it just seems kludgy -- if you want a
> procedure that does nothing, then write a procedure that does nothing.
I don't want a routine that does nothing, I don't want any logging at all.
@@ -916,7 +988,7 @@
to get executed (the code size used to matter, too).
...
-> For logging, yes. But it's not often you want a do-nothing default
+> For logging, yes. But it's not often you want a do-nothing default
> for anon-access-to-subp params.
I would have just said "it's not often you want ... anon-access-to-subp
@@ -924,7 +996,7 @@
and Preelaborated packages make the normal solution impossible.
...
-> Anyway, presumably "X: not null access procedure(...)" will still be
+> Anyway, presumably "X: not null access procedure(...)" will still be
> legal. I would strongly object if "X:
> procedure(...)" allowed X to be null.
@@ -942,12 +1014,29 @@
****************************************************************
-From: Jeam-Pierre Rosen
+From: Jean-Pierre Rosen
Sent: Friday, April 14, 2017 11:47 PM
-> For what it is worth in ParaSail, there are subprogram values, and a
+> For what it is worth in ParaSail, there are subprogram values, and a
> "null" procedure value does nothing.
Too bad you didn't call it "OM" ...
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, June 9, 2017 6:50 PM
+
+Here is a first cut at wording for this AI. (This is version /02 of the AI
+ - Editor.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 9, 2017 8:59 PM
+
+Thanks. We still need a !problem, !summary, and !discussion. And for me at
+least, we need this to work on generic formal subprograms, as those are an
+access-to-subprogram analogue.
****************************************************************
Questions? Ask the ACAA Technical Agent