CVS difference for ai05s/ai05-0005-1.txt
--- ai05s/ai05-0005-1.txt 2011/11/01 05:32:50 1.41
+++ ai05s/ai05-0005-1.txt 2012/01/05 06:19:31 1.42
@@ -2580,7 +2580,116 @@
****************************************************************
-Editor's note (October 31, 2011): All of the items above this
+From: Steve Baird
+Sent: Friday, November 4, 2011 6:55 PM
+
+The AARM says this about 10.2.1(18/3) (pure call permissions):
+
+ A declared-pure library_item has no variable state. Hence, a call on
+ one of its (nonnested) subprograms cannot normally “normally” have
+ side effects. The only possible side effects from such a call would be
+ through machine code insertions, imported subprograms, unchecked
+ conversion to an access type declared within the subprogram, and
+ similar features. The compiler may omit a call to such a subprogram
+ even if such side effects exist, so the writer of such a subprogram
+ has to keep this in mind.
+
+Contrary to what this commentary suggests, it seems that a (loosely speaking)
+"pure" function can have side-effects without going outside the fully portable
+subset of Ada by using indirect calls to gain access to variable state.
+
+ package Pure_Pkg is
+ pragma Pure;
+ function Foo (X : Some_Tagged_Type) return Integer;
+ end;
+
+ package body Pure_Pkg is
+ function Foo (X : Some_Tagged_Type) return Integer is
+ begin
+ return Some_Dispatching_Function (Some_Tagged_Type'Class (X));
+ -- dispatches to code that has side effects
+ end Foo;
+ end Pure_Pkg;
+
+There is a similar situation with access-to-subprogram calls.
+
+I could certainly imagine a user being surprised if a compiler (as part of
+code generation) transforms
+
+ while Pure_Pkg.Foo (X) /= 0 loop
+ ...
+ end loop;
+
+into
+
+ Temp := Pure_Pkg.Foo (X);
+ if Temp /= 0 then
+ -- infinite loop if we get here
+ loop
+ ...
+ end loop;
+ end if;
+
+It is not clear that any language changes are needed here, but I think that
+the AARM paragraph is significantly misleading and that something like the
+following would be an improvement:
+
+ A declared-pure library_item has no variable state. Hence, a call on
+ one of its (nonnested) subprograms cannot normally “normally” have
+ side effects. Side effects are still possible via dispatching calls
+ and via indirect calls through access-to-subprogram values. Other
+ mechanisms that might be used to modify variable state include
+ machine code insertions, imported subprograms, and unchecked
+ conversion to an access type declared within the subprogram; this
+ list is not exhaustive. Thus, the permissions described in this
+ section may apply to a subprogram whose execution has side-effects.
+ The writer of such a subprogram has to keep this in mind.
+
+If it is decided that language changes are needed here because the current
+treatment of the example given above is unacceptable, then we have a lot of
+discussion ahead of us. I'm suggesting that we should at least accurately
+describe the current situation even if we aren't going to fix it right now.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 14, 2011 4:30 PM
+
+I hope you can handle this as a minor editorial correction to AARM-7.6(17.k/3):
+
+17.k/3 {AI05-0067-1} For function calls, we only require building in place
+ for immutable types. ...
+ ^^^^^^^^^
+
+"immutable" should be "immutably limited". "immutable" means various things,
+including "discriminants can't change", which is not what was meant here.
+
+****************************************************************
+
+From: Christoph Grein
+Sent: Wednesday, November 16, 2011 1:50 AM
+
+2.1(6.a/2) ... as future characters can [be] already be used in Ada character
+and string literals.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Wednesday, December 28, 2011 10:46 AM
+
+A.18.18 (49.a/3) "*Implementation Note: *The “tamper with the element”
+check is intended to prevent the Element parameter of Process
+from being [modified] {replaced} or deleted outside of Process."
+
+The definition of tampering only covers deletion (or complete
+replacement) of the Element. Modifying the element is not defined to be associated
+with tampering with the element.
+
+[Editor's note: There is a similar problem in A.18.2(137.a/2).]
+
+****************************************************************
+
+Editor's note (December 30, 2011): All of the items above this
marker have been included in the working version of the AARM.
****************************************************************
Questions? Ask the ACAA Technical Agent