CVS difference for ais/ai-00359.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00359.txt

--- ais/ai-00359.txt	2003/09/30 01:41:29	1.1
+++ ais/ai-00359.txt	2003/09/30 02:01:14	1.2
@@ -1,11 +1,13 @@
-!standard 13.14     (05)                               03-07-25  AI95-00369/01
+!standard 12.03     (12)                               03-09-29  AI95-00359/02
+!standard 12.03     (20)
+!standard 13.14     (05)
 !class amendment 03-07-22
 !status work item 03-09-29
 !status received no action 03-07-22
 !status received 03-04-14
 !priority Low
 !difficulty Medium
-!subject Relaxed freezing rules for generic instantiations
+!subject Deferring Freezing of a Generic Instantiation
 
 !summary
 
@@ -18,7 +20,7 @@
 For such an instantiation, no special freezing happens
 at the point of the instantiation, other than the freezing
 that is due to the elaboration of the declarations within
-the "spec" of the instantiation.   Elaboration of the body
+the "spec" of the instantiation. Elaboration of the body
 of the instantiation is deferred until a "general" freezing
 point occurs, which occurs at the end of the enclosing
 library unit or declarative part, upon encountering a "real" body, etc.
@@ -33,7 +35,7 @@
 
 !problem
 
-Ada 95 provides formal package parameters.  One way of using
+Ada 95 provides formal package parameters. One way of using
 these parameters is to define a "signature" for a class of abstractions,
 such as all set abstractions, or all physical unit abstractions, and
 then build a new generic abstraction on top of the original
@@ -98,7 +100,7 @@
 units AI (AI-00324).]
 
 A similar problem occurs when a type wants to include a pointer
-to a container based on the type being defined.  For example:
+to a container based on the type being defined. For example:
 
     package Expressions is
 	type Expr_Ref is private;
@@ -132,7 +134,38 @@
 
 !wording
 
-(See summary.)
+Change paragraph 12.3(12) as follows:
+   A generic_instantiation declares an instance; it is equivalent to the
+   instance declaration (a package_declaration or
+   subprogram_declaration) followed [immediately] by the instance body[,
+   both at the place of the instantiation]. {The instance declaration
+   is located at the place of the instantiation. The instance body is
+   located immediately following the instance declaration if none of the
+   actual parameters denote types that are not yet completely defined.
+   If one of the actual parameters denotes a type not completely
+   defined, the location of the instance body is immediately prior to
+   the next non-instance body, or the end of the nearest enclosing
+   declarative_part or library_item.}
+
+Change paragraph 12.3(20) as follows:
+   ... Finally, the instance declaration [and body are] {is} elaborated.
+   {The instance body is elaborated either immediately following the
+   instance declaration, or deferred until the next non-instance body or
+   end of the enclosing declarative_part or library_item if there are
+   any actuals that denote types that are not yet completely defined.}
+
+Change paragraph 13.14(5) as follows:
+  * The occurrence of a generic_instantation causes freezing {except
+    when one of the actual parameters denotes a type that is not yet
+    completely defined}; also, if a parameter of [the] {an}
+    instantiation {that causes freezing} is defaulted, the
+    default_expression or default_name for that parameter causes
+    freezing. {For an instantiation that does not cause freezing, the
+    constructs of the instance declaration cause freezing according to
+    the rules of this clause. The elaboration of the instance body is
+    deferred until the end of an enclosing construct or a non-instance
+    body which would cause freezing of all enclosed or prior
+    declarations.}
 
 !example
 
@@ -152,7 +185,7 @@
 This proposal makes it possible for a generic instantiation
 to be used in more places than before, since it can
 be used with a private type before the type is completely
-defined.  As things stand now, it is often necessary to
+defined. As things stand now, it is often necessary to
 completely restructure things to be able to use a generic
 container as part of defining a private type.
 
@@ -341,6 +374,185 @@
 
 As a user of Ada, I would find this relaxation of the freezing rules to
 be of *huge* benefit.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, September 28, 2003  4:24 PM
+
+Here is an update to an AI that never made
+it into the AI database.  (I think the editor might
+be doing some editorializing ... ;-).
+Basically, I added wording.
+
+Personally, I think this is an important AI,
+because it enables an important use of generic
+signatures on private types, but also makes
+generics more flexible in general.
+
+[Editor's note: This is version /02 of the AI.]
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Sunday, September 28, 2003  4:24 PM
+
+If you look at the procedures, you'll see that "if the Editor, in
+consultation with the Rapporteur, determines that a comment ...  is of
+interest to only a tiny minority of users, the commentary is given a
+status of Received No Action".  This is what happened to your previous
+submission on this topic, and it was filed as AC95-00060/01.  The
+procedures specify that, to resurrect this proposal from the dead, it
+must have the support from two ARG members.  So you need to find someone
+else who is excited about mucking with the freezing rules.
+
+I am not trying to make a nuisance of myself, but as we are nearing the
+deadline for adding new stuff to the Amendment, I am going to insist
+that we go by the book: there is no point in spending precious ARG time
+on proposals that don't have a modicum of support from the group.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, September 29, 2003  7:16 AM
+
+Well if I remember correctly, Bob Duff
+said "attaboy!" when I submitted this proposal.
+So I only need one more ;-).
+
+(I promise I didn't intend to violate procedures,
+but I was unaware that it had been classified
+as "no action."  I thought that was reserved for
+proposals that clearly had little merit.  I had the
+sense that mine was a bit above that level, but
+apparently not...)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, September 29, 2003  2:39 PM
+
+As I said Bob Duff I believe expressed support for this proposal.
+Is that enough, or do you want another?  If so, anyone out there
+interested in making generics more useful by relaxing these
+freezing rules?  Please speak up now!
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, September 29, 2003  3:37 PM
+
+> As I said Bob Duff I believe expressed support for this proposal.
+> Is that enough, or do you want another?  If so, anyone out there
+> interested in making generics more useful by relaxing these
+> freezing rules?  Please speak up now!
+
+Yes, I do support this.
+
+Put your user hats on, please, and take off your implementer and
+language lawyer hats.  This is one of the most frustrating parts of Ada.
+
+I want to write "package P is new G(T);" in the same package as T.
+But that's illegal.  So a huge amount of restructuring is required.
+
+Quite often, "G" is some sort of "growable sequence of T", or whatever,
+and T *contains* such a sequence.  So it's no good to put P in a child.
+Type T *needs* visibility upon the instance, P.
+
+Note that if "sequence of T" happened to be "array of T", all would be
+well.  But surely, replacing "array of T" with "Growable_Seq_Of_T"
+should not require such major restructuring of the code.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, September 29, 2003  3:44 PM
+
+I'll add my second.  I agree this is worth discussing.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, September 29, 2003  5:45 PM
+
+> I want to write "package P is new G(T);" in the same package as T.
+> But that's illegal.  So a huge amount of restructuring is required.
+
+Tweet!!! Excessive use of generics! 15 yard penalty from the spot of the
+foul!
+
+(Sorry, it's football season. :-)
+
+No, that has never, ever happened to me as an Ada user. OK, I can see how it
+could happen with some models. But I think you're overstating the likelihood
+of this case in practice. This is just like the 'problem' discussed in AARM
+13.14(19.q-s), in which the premise is faulty (it's not important, no one
+writes code like that), which of course leads to faulty rules which are
+unnecessarily hard to implement.
+
+But, merits of the problem aside, does it bother others (like it does me)
+that the proposed 'solution' is to change the freezing and elaboration rules
+of the language in order to 'fix' what is essentially a visibility problem?
+What Bob needs is a partial view of a generic to go along with partially
+viewed type.
+
+This proposal has two serious technical problems:
+
+1) Changing some unrelated type far away from an instantiation silently
+changes the semantics of the instantiation. A program can start failing with
+Program_Error simply because a type was changed to be a private type.
+
+2) The changes to the elaboration model of instantiations are substantial.
+Ada 83 is carefully designed so that once an instantiation is elaborated, no
+elaboration checks are needed on the use of anything in that instantiation.
+Changing that will have gigantic effects all over compilers - most of the
+elaboration assumptions will be invalid. (I wonder what this would do to the
+GNAT static elaboration model?)
+
+And then there is freezing and generics. This is a dead body issue for me -
+relaxing the freezing rules is simply impossible: we're generating the code
+for a generic at the point that it is seen.
+
+So, I'll be bringing an extra shoe along to the meeting (I don't want to
+cause anyone to pass out by taking mine off).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, September 29, 2003  8:59 PM
+
+Here's part of a note that I sent to Pascal when we were discussing what to do
+with this proposal:
+
+----
+
+Anyway, it occurs to me that the main problem could be solved with an
+"incomplete" instantiation. To show Tucker's original example:
+
+    generic
+        type Elem is private;
+        with function Hash(El : Elem) return Integer;
+    package Hashed_Sets is
+        type Set is private;
+        function Union(Left, Right : Set) return Set;
+        ...
+        incomplete package Signature is new Set_Signature(Elem, Set);
+    private
+        type Set is record
+           ...
+        end record;
+        package Signature is new Set_Signature(Elem, Set);
+    end Hashed_Sets;
+
+(Syntax to be chosen.) This would make the instantiation available anywhere
+after it is completed (which would include all external users), but nothing
+from it could be used until that point. (We could go further and export
+incomplete types or something like that, which would fix Tucker's second
+example, but I don't think that complication is really necessary.)
+
+The point is to allow an instantiation that has to be elaborated in the private
+part still be to visible; it also makes the deferred elaboration crystal clear.
+(Of course, it isn't really deferred.)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent