CVS difference for ais/ai-00359.txt

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

--- ais/ai-00359.txt	2004/06/10 04:21:51	1.5
+++ ais/ai-00359.txt	2004/06/25 00:55:45	1.6
@@ -150,7 +150,7 @@
          Legality Rules
 
     A pragma Deferred_Freezing_Point that applies to a given
-    generic_instantiation shall preceed any construct (outside the
+    generic_instantiation shall precede any construct (outside the
     instance itself) that causes freezing of an entity defined by the
     generic_instantiation.
 
@@ -1858,6 +1858,107 @@
 seem to find this in the AI.  Obviously for an instantiation which is a
 subprogram the local_name is not enough to denote a particular
 instantiation.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 10, 2004  7:44 AM
+
+I mispelled "precede" at least once in this AI.
+Sorry about that.
+
+As far as applying to subprogram instantiations
+that are overloaded, I would go the route of pragma
+Inline and say it applies to all overloadings
+that are instances, and their freezing and
+body elab all take place at the point of
+the pragma.  This seems like a highly unlikely
+case to begin with, so almost anything that
+doesn't muck up the basic capability would
+seem OK.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 10, 2004  10:02 AM
+
+Actually, perhaps this is a waste of energy.
+Since we already support renaming as body as
+a way to postpone a subprogram instantiation
+into a private part, we might as well make this
+pragma be available only for package instantiations.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Sunday, June 20, 2004  1:16 PM
+
+First, I am very much in favor of fixing this problem.  The inability to
+instantiate generics where I want to has caused a lot of damage to the
+structure of my programs (making types public when they should be
+private, introducing gratuitous indirections of various sorts, and
+various other workarounds).
+
+----------------
+
+I don't much like the name of this pragma.  Freezing is an arcane
+obscurity that shouldn't be mentioned in polite company.  That's why
+it's banished to chap 13.
+
+Why don't we look at it this way: the *body* of the instance is what
+causes freezing of all manner of things (because we don't want to look
+inside it -- the contract model).  By default, the body of the instance
+occurs at the same place as the spec -- namely, at the place of the
+instantiation.  This new pragma provides a way to put the body of the
+instance somewhere else.
+
+So we could call it pragma Place_Instance_Body_Here, or just
+Place_Instance_Body, or just Instance_Body, or something along those
+lines.
+
+----------------
+
+The reason we need a pragma (or the proposed restriction of alternative
+AI-359-02) is, I presume, upward compatibility.  We don't want to move
+the place where the elaboration happens.
+
+Is that really a serious concern?  I find it difficult to imagine a
+generic that would care so precisely when its instance's body gets
+elaborated.
+
+I can live with the pragma (especially if it has a better name), but I
+think I'd prefer just fixing the problem directly.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 23, 2004  9:58 PM
+
+> Is that really a serious concern?  I find it difficult to imagine a
+> generic that would care so precisely when its instance's body gets
+> elaborated.
+
+There are at least two problems:
+
+-- All Ada compilers use a single elaboration check at the point of the
+instantiation, rather than checking the items individually. Changing that
+would be rather pervasive, and would have a (small) performance
+incompatibility.
+
+-- Doing complex things at elaboration-time *appears* useful. So journeyman
+Ada programmers try to do clever things there. I've seen quite a bit of such
+code, and written some myself. Once you get to be an expert, you realize
+that such things are fragile, and stop doing them -- replacing them with
+explicit calls or controlled type initialization. But there is an awful lot
+of fragile code out there that does weird things at elaboration time. (I
+used to have lots of code that read from a configuration file - the order
+mattered a lot there.) Breaking that by changing elaboration ordering is the
+worst kind of incompatibility (it happens silently with no indication of any
+kind).
+
+Since it is the worst kind of incompatibility, we need to avoid it unless
+we're certain that it doesn't happen in practice. But I think it's likely
+that it does occasionally happen in practice.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent