CVS difference for ai05s/ai05-0005-1.txt

Differences between 1.41 and version 1.42
Log of other versions for file 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