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

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0019-1.txt

--- ai05s/ai05-0019-1.txt	2006/12/16 03:13:18	1.4
+++ ai05s/ai05-0019-1.txt	2007/01/19 04:00:06	1.5
@@ -685,3 +685,65 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Date: Monday, January 15, 2007  8:00 PM
+
+A summary of the minutes of 31st ARG meeting says:
+
+The solution seems to be to partially freeze the subprogram when the
+type is frozen. That is, freeze the subprogram but not the parameters.
+Randy suggests that we might separate freezing the subprogram and
+freezing the profile. (The profile would be frozen by calls, etc.)
+13.14(14) says that the callable entity freezes its profile; weíd need
+to break that. The profiles would have to be frozen at the end of the
+unit (in the normal way). What bad would happen if we did that? No one
+has any real problems.
+
+Tucker suddenly announces that we donít need any rules to freeze the profile:
+he thinks the types will be frozen by a call or instantiation or default expression.
+
+---
+
+I donít buy Tuckerís idea. I donít see anything other than the first sentence
+of 13.14(14) that would freeze the result of a function call. Yes, any program
+with a problem would necessarily raise Program_Error, but that would violate
+the meta-rule Bob described so eloquently:
+
+"General principle: it's silly to require a compiler to deduce some fact, and
+respond by generating code to raise an exception.  If we're going to require
+such a deduction, the response should be a (legality) error message.  And it's
+our duty to write down what needs to be deduced, rather than leaving it
+implicit."
+
+Consider a program like your example from that AI (AI05-0017-1):
+
+	package Stt is 
+	    type T is tagged private; 
+	    function F return access T'Class; 
+	    function G (X : access T) return Integer; 
+	    I : Integer := G (F); 
+	private
+	    type T is tagged null record; 
+	end Stt;
+
+Surely we want the call of G(F) to freeze F and more importantly, the result
+type of F. I donít see anything other than 13.14(14) that has that effect. So,
+Danger, Will Robinson. ;-)
+
+I think my original idea of profile freezing would work. Indeed, it might in fact
+only be necessary to define it for calls. That would seem to be less dangerous
+anyway (why change what isnít a problem?).
+
+Pascal privately replied:
+
+Last time I gave some thought to the matter, while shaving, I came to the
+conclusion that we actually needed to freeze profiles. Tuckís proposal would
+bring us dangerously close to Ada 83ís forcing occurrences.
+
+To which I reply:
+
+Hope you were not shaving with a blade. It's dangerous to think about freezing
+while shaving with a blade...could lose a nose or ear!
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent