CVS difference for ais/ai-00064.txt

--- ais/ai-00064.txt	1999/10/08 23:41:05	1.6
+++ ais/ai-00064.txt	2000/04/14 01:45:06	1.7
@@ -1,4 +1,4 @@
-!standard 03.11    (10)                               99-10-07  AI95-00064/08
+!standard 03.11    (10)                               00-04-12  AI95-00064/09
 !standard 03.11.01 (01)
 !standard 08.05.04 (08)
 !class binding interpretation 95-07-06
@@ -73,6 +73,9 @@
     equivalent to the execution of a subprogram_body that simply calls
     the renamed subprogram with the same parameters.
 
+Change the freezing rule in 13.14(3) to exclude renaming-as-body from
+the freezing rules.
+
 !discussion
 
 Since the elaboration of a renaming-as-body may evaluate expressions, it
@@ -95,6 +98,16 @@
 See AI95-00135 for a discussion of circularities involving
 renamings-as-body.
 
+This issue also adds the missing definition of lower-case "body". This change
+makes a renaming-as-body a body. However, doing so triggers the freezing
+rule 13.14(3): "A noninstance body other than a renaming-as-body causes
+freezing of each entity declared before it within the same declarative_part."
+It clearly was the intent of the designers of the language that
+renaming-as-body not freeze (otherwise the second sentence of 8.5.4(5) could
+never be true), and existing compilers do not freeze when a renaming-as-body
+is encountered. We do not want to change this behavior, so we add an exception
+to 13.14(3).
+
 !corrigendum 3.11(10)
 
 @drepl
@@ -137,6 +150,20 @@
 parameters as the actual parameters and, if a function, returns the value of
 the call.
 
+!corrigendum 13.14(3)
+
+@drepl
+The end of a @fa<declarative_part>, @fa<protected_body>, or a declaration of a
+library package or generic library package, causes @i<freezing> of each entity
+declared within it, except for incomplete types. A noninstance body causes
+freezing of each entity declared before it within the same @fa<declarative_part>.
+@dby
+The end of a @fa<declarative_part>, @fa<protected_body>, or a declaration of a
+library package or generic library package, causes @i<freezing> of each entity
+declared within it, except for incomplete types. A noninstance body other than
+a renaming-as-body causes freezing of each entity declared before it within the
+same @fa<declarative_part>.
+
 !ACATS test
 
 ACATS test C854002 was constructed to check this ruling, and checks cases
@@ -290,5 +317,220 @@
 
 - Bob
 
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, April 03, 2000 4:19 AM
+
+Dear ARG members that were not in Phoenix,
+
+On one of the TC items we ran into secondary technical problem. Rather
+than have you wait for the minutes, I want to solicit your opinion on
+the issue now.
+
+The wording change for the AI that resolves the elaboration question
+includes a renaming-as-body in the semantic category "body". However,
+noninstance bodies freeze all entities declared before them.
+
+We had a choice to make and we chose to explicitly exclude renaming-as-body
+from this freezing rule, largely because we did not want to mess with the
+presumed designers' intent that renames don't cause freezing. We noted,
+however, that such freezing would solve the circular renaming AI (and the
+taking of the convention from the renamed subprogram) trivially.
+
+Was our choice the right one ?  If you believe that we should make
+renaming-as-body a cause for freezing, speak up now.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, April 03, 2000 8:41 AM
+
+This seems very wrong to me. Renaming-as-body should be semantically
+equivalent to the expanded body. Indeed on GNAT that's all it is. I
+suppose some glitch can be programmed into the implementation to make
+this a special case, but I would find this non-equivalence weird from
+a semantic point of view anyway.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, April 03, 2000 9:07 AM
+
+I agree.
+
+If you think of maintenance it's likely that some bodies will need to be changed
+from a renaming-as-body to a true body (or vice-versa).  This should be possible
+without affecting the legality of the code.
+
+The current rules already make sure that you can switch between a subunit and a
+proper body without trouble.  I see no reason to use different rules for a
+renaming-as-body.
+
+Incidentally our compiler current does not consider that a renaming-as-body
+freezes, but changing that is a one-liner.
+
+****************************************************************
+
+From: Ed Schonberg
+Sent: Monday, April 03, 2000 8:36 AM
+
+GNAT does not treat the renaming_as_body as a freezing point, we see no
+reason to change the rule, so we are happy with the exclusion.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, April 03, 2000 9:23 AM
+
+Renaming as body should not freeze in my opinion.
+I think it is important that you can declare several subprograms in the
+visible part, and then complete them in the private part via renaming,
+without losing the possibility that non-Ada conventions are carried
+over from the renamed entity.  E.g.:
+
+    type My_Int is private;
+    function Plus(L, R : My_Int) return My_Int;
+    function Minus(L, R : My_Int) return My_Int;
+  private
+    type My_Int is new Integer;
+    function Plus(L, R : My_Int) return My_Int renames "+";
+    function Minus(L, R : My_Int) return My_Int renames "-";
+
+This would not work if the first renaming-as-body froze things.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, April 03, 2000 9:35 AM
+
+Ed said
+
+<<GNAT does not treat the renaming_as_body as a freezing point, we see no
+reason to change the rule, so we are happy with the exclusion.
+>>
+
+OK, so implementation is not an issue in terms of GNAT.
+
+I still find it an odd difference, but am not willing to argue strongly
+against the majority conclusion :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, April 03, 2000 9:52 AM
+
+Robert Dewar wrote:
+>
+> This seems very wrong to me. Renaming-as-body should be semantically
+> equivalent to the expanded body. Indeed on GNAT that's all it is. I
+> suppose some glitch can be programmed into the implementation to make
+> this a special case, but I would find this non-equivalence weird from
+> a semantic point of view anyway.
+
+There are really two kinds of renaming-as-body.  One which
+happens before the spec is frozen, and one after the spec is
+frozen.  If the spec is not yet frozen, the renaming-as-body
+must be treated essentially like a deferred renaming-as-spec.
+The renaming-as-body is "seen" by all callers in this case,
+so you can really just redirect the call to the renamed routine.
+
+A renaming-as-body after the spec is frozen really has to produce
+an out-of-line body, even if it consists of only a "jump," unless
+you can play various link-time games with redirecting one link-name
+to bind to another (of course, that doesn't work if the renaming-as-body
+renames blah.all).
+
+So I suppose it would be OK if a renaming-as-body after the spec
+is frozen also froze other stuff, but I worry about incompatibilities
+where there are several "early" renaming-as-bodies with one
+"late" one interspersed, thereby converting all the remaining
+"early" renamings into late ones, and preventing non-Ada conventions.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, April 03, 2000 9:55 AM
+
+<<Incidentally our compiler current does not consider that a
+renaming-as-body freezes, but changing that is a one-liner.>>
+
+It is vaguely worrying that both Rational and GNAT are "wrong"
+here if we change it. What about other Ada 95 front ends?
+
+There is an argument for maintaining the current *behaviuor* if it is
+uniform.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Monday, April 03, 2000 10:34 AM
+
+Pascal says:
+> If you think of maintenance it's likely that some bodies will need to be
+> changed from a renaming-as-body to a true body (or vice-versa).  This
+> should be possible without affecting the legality of the code.
+
+Ahh, so we need to change the syntax rules to allow proper bodies in
+package specs.  I wonder if Robert will insist that it be non-binding?
+
+;-) ;-)
+
+During the 9X project, I had the same reaction as Robert: it's ugly for
+renaming-as-body to be anything but a short-hand.  We discussed the
+issue of freezing, in particular.  Tucker overruled me at the time,
+putting usefulness ahead of uniformity.  There's no reason to change
+that decision now.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, April 04, 2000 2:51 AM
+
+Yes, to be honest I keep forgetting that a renaming-as-body is legal in a spec.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, April 05, 2000 5:05 AM
+
+To be really honest, I did not know (or have forgotten) that it is
+legal in a spec. How odd .. seems a real mistake to me, precisely
+because it is not orthogonal to the idea of it simply being an
+abbreviation.
+
+A nice example of how simplicity at the definitional level (which is
+hopefully improved by this peculiar feature) is so different from
+simplicitly at the learning level (allowing this in a spec definitely
+makes it harder to understand at least to me). Reminds me of
+
+ a : aliased string := "asef"
+
+and
+
+ a : aliased string (1 .. 4) := "asef";
+
+being different.
+
+Well I guess since this feature is odd, and has no simple semantic
+explanation as expansion into a body, making it a bit odder by having
+(what appears to the uninitiated as) an exception to the expected
+freezing by a body is no big deal.
+
+After all one cannot imagine a program being damaged by the *lack* of
+freezing, so if all implementations avoid the freeze, I don't see any
+real harm.
+
+I do see harm if we change implementations the other way, since this
+can indeed cause working programs to fail.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Wednesday, April 05, 2000 8:06 AM
+
+Generic instantiations can cause bodies to appear in specs, even though
+bodies are syntactically illegal in specs.  Strange, perhaps, but we've
+learned to live with it.
 
 ****************************************************************