CVS difference for ai05s/ai05-0074-2.txt

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

--- ai05s/ai05-0074-2.txt	2008/08/14 04:38:09	1.4
+++ ai05s/ai05-0074-2.txt	2008/10/25 04:53:14	1.5
@@ -5993,3 +5993,809 @@
 
 ****************************************************************
 
+From: Edmond Schonberg
+Date: Thursday, August 14, 2008  7:47 AM
+
+> But I don't want to rule any idea out-of-hand, as nothing has worked 
+> that well so far...
+
+Indeed, and I would like to put back on the table a suggestion we discarded
+months ago, but which now seems like a much smaller change to the description
+of the language (even though it might be an implementation earthquake).
+It is simply to say that an instantiation does not freeze the actuals: they
+become frozen in the normal course of things AFTER the instantiation. I
+realize that Pascal was vociferously opposed to this, and so was I, because
+freezing rules are an extremely delicate part of each implementation.  
+However, all the proposals so far propose a complex mechanism that will be
+hard to graft onto existing implementations, complex to explain, and contribute
+to the general complexity of the language for a very small gain.  By contrast,
+removing 13.14 (5) is almost invisible (except for implementors!).  I'd be
+willing to experiment with this is GNAT, but of course other implementors
+would have to do the same for the experiment to be convincing.
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, August 14, 2008  11:24 AM
+
+A related proposal was also discarded on the grounds that it would involve
+changes to the freezing rules. We had discussed the idea of providing a
+mechanism to somehow defer the elaboration of a package instance body so
+that it did not occur directly after the elaboration of the instance spec.
+This change in the dynamic semantics would be accompanied by a change in
+the freezing rules so that the freezing associated with an instance spec
+would be performed as for an ordinary package spec and the wholesale
+freezing associated with the instance body would be performed at the point
+where the instance body is elaborated.
+
+If we are willing to consider changes to the freezing rules, then we might
+want to reconsider this approach (which, incidentally, handles the case of
+a generic body which declares an object of a formal type).
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Thursday, August 14, 2008  11:34 AM
+
+> A related proposal was also discarded on the grounds that it would 
+> involve changes to the freezing rules. We had discussed the idea of 
+> providing a mechanism to somehow defer the elaboration of a package 
+> instance body so that it did not occur directly after the elaboration 
+> of the instance spec. This change in the dynamic semantics would be 
+> accompanied by a change in the freezing rules so that the freezing 
+> associated with an instance spec would be performed as for an ordinary 
+> package spec and the wholesale freezing associated with the instance 
+> body would be performed at the point where the instance body is 
+> elaborated.
+
+Was this just a change in the freezing rules, or did it involve some syntax?
+I don't recall.  Changing the rules so that the instance spec is treated
+like any local package is what I have in mind to experiment with.
+
+> If we are willing to consider changes to the freezing rules, then we 
+> might want to reconsider this approach (which, incidentally, handles 
+> the case of a generic body which declares an object of a formal type).
+
+I trust that the Baird's "here be dragons" examples are to follow shortly...
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, August 14, 2008  11:46 AM
+
+> If we are willing to consider changes to the freezing rules, then we 
+> might want to reconsider this approach (which, incidentally, handles 
+> the case of a generic body which declares an object of a formal type).
+
+I really find approaches based on changing the freezing rules to be far
+preferable from a user point of view.
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, August 14, 2008  1:46 PM
+
+> Was this just a change in the freezing rules, or did it involve some 
+> syntax? I don't recall.
+
+I don't think we got that far.
+The precise details for specifying the point at which an instance body
+is to be elaborated remain to be worked out.
+Using either syntax or pragmas, one could imagine specifying either
+just a boolean value (i.e., an indication that the body elaboration of
+an instance is to be deferred; the point at which elaboration would then
+occur would be defined by the language to be something like the end of
+the enclosing package spec or the beginning of the enclosing body or
+somesuch) or perhaps a more precise indication of where the body is to
+be elaborated (e.g., pragma Elaborate_The_Body_Right_Here (My_Instance)).
+
+It would be possible (although I don't suggest this) to address this problem
+without either pragmas or syntax changes. The idea is to change the
+freezing rules and the dynamic semantics in a way that only affects
+programs that would previously have been illegal because of freezing rule
+violations. We go with the proposed fine-grained freezing model for package
+instance specs. If the wholesale freezing associated with the instance body
+wouldn't introduce any legality violations at the point of the instantiation,
+then that freezing is performed and the instance body is elaborated at the
+usual place. If, however, that freezing would introduce a legality violation,
+then we (statically) defer the freezing and (dynamically) defer the body
+elaboration until the end of the enclosing package spec.
+
+The thing I don't like about this approach is that a minor change whose
+significance is difficult to appreciate without an understanding of the
+freezing rules could change the point at which an instance body is
+elaborated. I suspect that users (e.g., me) would find this confusing.
+
+If it seemed important enough, we could introduce some mechanism for either
+specifying or confirming (like overriding_indicators) that the elaboration
+of a given instance body is or is not deferred.
+
+> I trust that the Baird's "here be dragons" examples are to follow 
+> shortly...
+> 
+
+I actually like this general approach. Any change in the point at which
+a body is elaborated would require a corresponding change in the point
+at which it is finalized. The new rules would need to handle the case
+of a package that declares multiple package instances. That's all that
+comes to mind at the moment.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Thursday, August 14, 2008  2:11 PM
+
+> The thing I don't like about this approach is that a minor change 
+> whose significance is difficult to appreciate without an understanding 
+> of the freezing rules could change the point at which an instance body 
+> is elaborated. I suspect that users (e.g., me) would find this confusing.
+> If it seemed important enough, we could introduce some mechanism for 
+> either specifying or confirming (like overriding_indicators) that the 
+> elaboration of a given instance body is or is not deferred.
+
+It seems unlikely that anybody cares when their instance bodies get elaborated.
+Elab code normally initializes the thing itself, and doesn't reach out and
+cause "interesting" side effects that matter to other parts of the program.
+So I can't get too excited about this issue -- even if it's not strictly compatible.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, August 14, 2008  2:12 PM
+
+> Indeed, and I would like to put back on the table a suggestion we 
+> discarded months ago, but which now seems like a much smaller change 
+> to the description of the language (even though it might be an 
+> implementation earthquake).  It is simply to say that an instantiation 
+> does not freeze the
+> actuals: they become frozen in the  
+> normal course of things AFTER the instantiation.   I realize that  
+> Pascal was vociferously opposed to this, and so was I, because 
+> freezing rules are an extremely delicate part of each implementation.
+> However, all the proposals so far propose a complex mechanism that 
+> will be hard to graft onto existing implementations, complex to 
+> explain, and contribute to the general complexity of the language for 
+> a very small gain.  By contrast, removing
+> 13.14 (5) is almost invisible (except for implementors!).  
+> I'd be willing to experiment with this is GNAT, but of course other 
+> implementors would have to do the same for the experiment to be 
+> convincing.
+
+Apparently, I lied, because I *do* reject this idea out of hand. That's
+because we thoroughly discussed it in the past, and absolutely nothing as
+changed. I was referring to *new* ideas, not old, rejected ones.
+
+Two proposals for dealing with this is written up in AI95-0359-1 and
+AI95-0359-2. (The file names are AI-00359.TXT and AI-10359.TXT, in case
+you've forgotten the weird encoding we used to use). There's also a lot
+in the minutes of the various meetings that discuss these proposals, and
+in the !appendix. I really don't want to have to go over all of this same
+ground again.
+
+The main problem is that this requires not only wholesale changes to the
+freezing rules but also the elaboration rules (since the body of the
+generic needs to have access to the details of the actuals). We could
+not agree on where that elaboration would happen, and the effect on
+elaboration checking (currently, there is a single elaboration flag for
+any access to the entire generic; that's not going to work anymore). A
+generic instantiation is the only way to get an elaborated body into an
+Ada specification, so just elaborating at the end of the package would
+lose important capabilities. And elaborating at some random freezing point
+would mean that the elaboration could move by slight unrelated changes
+in the specification; that could introduce Program_Error where none
+existed before.
+
+And I surely agree with Steve's point (in a message that came while I
+was writing this one) that not marking these in some fashion would be a
+real maintenance hazard.
+
+All of these things can be addressed, but in doing so, we would lose
+the usability advantage that this supposedly would have. I'd rather not
+bother trying to fix the problem.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, August 14, 2008  2:53 PM
+
+> It seems unlikely that anybody cares when their instance bodies get elaborated.
+> Elab code normally initializes the thing itself, and doesn't reach out 
+> and cause "interesting" side effects that matter to other parts of the program.
+> So I can't get too excited about this issue -- even if it's not 
+> strictly compatible.
+
+I agree, in fact the sense of strong orderinng here is a language artifact,
+not somethingt he programmer is concerned with usually.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, August 14, 2008  3:22 PM
+
+> So I can't get too excited about this issue -- even if it's not 
+> strictly compatible.
+
+I strongly disagree. I outlined some of the reasons in my last message, but
+the most important one from a compatibility reason is access-before-elab checks.
+Currently, there aren't any for access to things in an instance. For
+example:
+
+    package P is 
+       Value : constant Boolean;
+       package Inst is new Gen ...;
+    private
+       Value : constant Boolean := Inst.Is_Valid ...;
+    end P;
+
+The call into Inst is always OK in Ada as it stands; it can't raise
+Program_Error.
+
+If we allow the body to elaboarate separately, we'll need to add
+access-before-elab checks to all of the contents of the generic body (and
+for Janus/Ada, given the code sharing, that would have a performance impact on
+*all* generics, whether they are instantiated this way or not). Moreover,
+this call could raise Program_Error because the body is not yet elaborated
+(that of course depends on the exact rule chosen). That seems like a serious
+incompatibly.
+
+As I mentioned in my last message, a generic instantation is the only way to
+get statements and other body code into the elaboration of a package
+specification. I've used generics that way a couple of times, and Pascal
+indicated that he had seen such uses as well. In that case, the generic itself
+is not that interesting, it is the side effect of the elaboration that is
+important. Breaking that would make any programs that depend on it extremely
+hard to maintain. (I admit that I don't do this anymore, because I've found
+it is too hard to control the order of elaboration. But my early Ada code
+initialized everything via elaboration, and that initialization had strong
+order dependencies that were not necessarily part of the specification.
+I know that many other Ada programmers have tried the same approach.)
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, August 14, 2008  3:29 PM
+
+> If we allow the body to elaboarate separately, we'll need to add 
+> access-before-elab checks to all of the contents of the generic body 
+> (and for Janus/Ada, given the code sharing, that would have a 
+> performance impact on *all* generics, whether they are instantiated 
+> this way or not). Moreover, this call could raise Program_Error 
+> because the body is not yet elaborated (that of course depends on the 
+> exact rule chosen). That seems like a serious incompatibly.
+
+That's certainly a point, although I think the time has come to stop the
+ceremonial worrying about impact on shared generics. However, in the big
+shceme of things I think this would be tolerable.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, August 14, 2008  3:52 PM
+
+> That's certainly a point, although I think the time has come to stop 
+> the ceremonial worrying about impact on shared generics. However, in 
+> the big shceme of things I think this would be tolerable.
+
+Nothing "ceremonial" about it, unless you are planning to offer me a job.
+;-) Part of my income comes from selling Janus/Ada, and that would be much
+harder to do if Janus/Ada could not claim to follow the Ada standard (modulo
+bugs and unimplemented features). And the effort to transition Janus/Ada
+away from generic code sharing would be immense; it would require
+redesign of intermediate code, project management, and other compiler
+areas (plus a huge bug slog). I don't think it could be financially
+justified. So, while every case is different, I'm not going to be moving
+away from beating the shared generics horse (dead or not).
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, August 14, 2008  4:41 PM
+
+What I am saying is that I really don't care if shared generics are
+inefficient at this stage, as long as they can be got to work at all that's
+good enough. It's time to stop letting efficiency of shared generics be
+a tail that wags the dog :-)
+
+So as long as there is a reasonable model for shared generics that's good
+enough. Yes, of course it will be inefficient in some cases in time, that's
+inevitable in any case, as long as it's not to extreme I think that's not
+something to worry about too much. In this particular case, I don't think it
+amounts to a significant argument that should influecne the design.
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, August 14, 2008  3:30 PM
+
+> It seems unlikely that anybody cares when their instance bodies get 
+> elaborated.
+
+If I started with this unit
+
+   with G;
+   pragma Elaborate_All (G);
+   package Foo is
+      type T is range 1 .. 10;
+      package I is new G (T);
+      X : Boolean := I.Some_Function;
+   end Foo;
+
+and decided to make T private (while still exporting the instance)
+
+   with G;
+   pragma Elaborate_All (G);
+   package Foo is
+      type T is private;
+      package I is new G (T);
+      X : Boolean := I.Some_Function;
+   private
+      type T is range 1 .. 10;
+   end Foo;
+
+then I think I would care if the call to I.Some_Function failed its
+elaboration check and propagated Program_Error.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, August 14, 2008  3:48 PM
+
+OK, I must admit, this is troublesome, elaboration is SUCH a pain!
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Thursday, August 14, 2008  3:46 PM
+
+The simplest is to say that all other freezing rules apply as before, so
+the reference to Some_Function in the call freezes it, and therefore its
+formals, etc.  Given that this also requires the body to be elaborated,
+this is the point at which the instance body must be materialized. There
+is no change in functionality for the user, there is no ambiguity as to
+where things are frozen, and there is no backwards compatibility: anything
+that compiled and ran properly before does so now.  From an implementation
+point of view, we could say that the body of the instance is elaborated
+at the point any entity from the instance spec is frozen.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, August 14, 2008  5:00 PM
+
+I don't think this quite works. You can't elaborate the body until pretty much
+everything in the spec. and all of the actuals are frozen. (That's certainly
+true for a shared body, where the contents of the generic instance descriptor
+need to be filled in first; and in any case, we don't want a legality
+dependency on the contents of the body, which may not even be known at
+compile-time of the instance.) You could freeze the entire instance if
+anything is frozen in it. But I know we discussed the "one touch and freeze
+everything" model in the past (see those AIs that I previously referenced),
+and it was strongly opposed by some people (not me; it's the only freezing
+change model that I think has even a slight chance of working in Janus/Ada);
+I don't recall the details as to why.
+
+****************************************************************
+
+From: Ed Schonberg
+Date: Thursday, August 14, 2008  5:19 PM
+
+I may have been one of the opponents, just because changing freezing
+rules gives everyone hives. However I would like to revisit this because
+it seems preferable to the other proposals in this thread. I agree that
+for now the only viable model is that freezing anything from the instance
+freezes everything.  The changes to the RM would be minuscule:
+a) Remove 13.14 (5)
+b) Add after 13.14 (15)
+    at the place where an entity from an instance is frozen, the actuals
+    of the instance are frozen. Also, if a parameter of the instantiation
+    is defaulted, the default_expression or default_name for that parameter
+    causes freezing.
+
+(is "entity from an instance" the proper term?)
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Thursday, August 14, 2008  5:35 PM
+
+> and decided to make T private (while still exporting the instance)
+> 
+>    with G;
+>    pragma Elaborate_All (G);
+>    package Foo is
+>       type T is private;
+>       package I is new G (T);
+>       X : Boolean := I.Some_Function;
+>    private
+>       type T is range 1 .. 10;
+>    end Foo;
+> 
+> then I think I would care if the call to I.Some_Function failed its 
+> elaboration check and propagated Program_Error.
+
+But that's currently illegal.  I can't get excited if it fails at elab time
+instead.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Thursday, August 14, 2008  5:40 PM
+
+> I strongly disagree. I outlined some of the reasons in my last 
+> message, but the most important one from a compatibility reason is 
+> access-before-elab checks. Currently, there aren't any for access to 
+> things in an instance. For
+> example:
+
+I suppose I should take your advice to read all the old AIs and minutes
+before commenting further on this...
+
+>     package P is 
+>        Value : constant Boolean;
+>        package Inst is new Gen ...;
+>     private
+>        Value : constant Boolean := Inst.Is_Valid ...;
+>     end P;
+> 
+> The call into Inst is always OK in Ada as it stands; it can't raise 
+> Program_Error.
+> 
+> If we allow the body to elaboarate separately, we'll need to add 
+> access-before-elab checks to all of the contents of the generic body 
+> (and for Janus/Ada, given the code sharing, that would have a 
+> performance impact on *all* generics, whether they are instantiated this way or not).
+
+Just one meta-comment: I am in favor of the language design goal "shared
+generic bodies (always-share, or sometimes-share) should be feasible".
+But I don't think it's possible to make the always-share model efficient,
+so I think we should tolerate inefficiencies there, within reason.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, August 14, 2008  6:06 PM
+
+> Just one meta-comment: I am in favor of the language design goal 
+> "shared generic bodies (always-share, or
+> sometimes-share) should be feasible".
+> But I don't think it's possible to make the always-share model 
+> efficient, so I think we should tolerate inefficiencies there, within 
+> reason.
+
+This echoes what Robert said, and I can't argue with that sentiment. What
+bothers me here is less the inefficiency itself than the fact that this
+will cause *existing* code that does *not* use this feature to be less
+efficient. Since Janus/Ada does elaboration checks inside of the called
+subprogram, it can't be removed unless the call is inlined or the check is
+known to never fail (as with some categorizations). This isn't a huge issue,
+because the added inefficiency is relatively small, but it is another
+downside to this proposal.
+
+The real big problem here is coming up with a set of freezing rules that
+allow the extra capability that we need but don't make shared implementations
+impossible or add all kinds of elaboration issues. And I completely disagree
+with the notion that people don't care where things are elaborated - it
+surely does not describe my programming nor many other examples that I am
+familiar with.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, August 14, 2008  6:13 PM
+
+> This echoes what Robert said, and I can't argue with that sentiment. 
+> What bothers me here is less the inefficiency itself than the fact 
+> that this will cause *existing* code that does *not* use this feature
+> to be less efficient.
+> Since Janus/Ada does elaboration checks inside of the called 
+> subprogram, it can't be removed unless the call is inlined or the 
+> check is known to never fail (as with some categorizations). This 
+> isn't a huge issue, because the added inefficiency is relatively 
+> small, but it is another downside to this proposal.
+
+Right, but static analysis could remove many of these elaboration checks,
+of course that would be tricky to do, but it is definitely possible.
+In practice, with GNAT nearly everyone uses the static elaboration model.
+So much so that actually it is legitimate to worry about any chganges
+in elaboration affecting this model. I don't see an issue in this particular
+case however.
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, August 14, 2008  6:30 PM
+
+> But that's currently illegal.  I can't get excited if it fails at elab 
+> time instead.
+
+I think you would agree that making an apparently innocuous transformation
+and then discovering that your program is illegal is preferable to
+inadvertently introducing a mysterious runtime error. If we modify the
+previous example by replacing the call "I.Some_Function" with
+"Almost_Always_True_But_Not_Quite_Always or else I.Some_Function", then
+we get a package spec which *usually* elaborates successfully but will fail
+occasionally.
+
+As you point out, the current language design disallows this example.
+The change we were discussing would have allowed it to compile but would
+have resulted in an elaboration check failure when I.Some_Function was called.
+
+In the case of this particular example, I think this would be a change for the
+worse.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Thursday, August 14, 2008  6:35 PM
+
+> In the case of this particular example, I think this would be a change 
+> for the worse.
+
+Yes, but is this a typical example? or a cooked up one?
+
+****************************************************************
+
+From: Steve Baird
+Date: Thursday, August 14, 2008  7:49 PM
+
+It's certainly true that elaboration check failures are typically not very
+difficult to diagnose.
+
+Perhaps you are right that this really wouldn't be much of a problem in
+practice.
+
+There goes my objection to the idea of performing freezing and body
+elaboration as per existing rules if this works and otherwise deferring the
+freezing and body elaboration points.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Friday, August 15, 2008  7:11 AM
+
+> > But that's currently illegal.  I can't get excited if it fails at 
+> > elab time instead.
+> 
+> I think you would agree that making an apparently innocuous 
+> transformation and then discovering that your program is illegal is 
+> preferable to inadvertently introducing a mysterious runtime error.
+
+Normally, I would, but in my book, elab failures are not "real" run-time
+errors -- they are essentially equivalent to link-time errors, because
+nless you do something strange, they happen every time.  Even the most
+minimal regression test suite will catch them.
+
+Well, the implementation is allowed to choose a different order each time,
+but that's a different complaint, and is irrelevant here.
+
+>... If we modify the
+> previous example by replacing the call "I.Some_Function" with  
+>"Almost_Always_True_But_Not_Quite_Always or else I.Some_Function", then  
+>we get a package spec which *usually* elaborates successfully but  will 
+>fail occasionally.
+
+Almost_Always_True_But_Not_Quite_Always must do some input (Text_IO.Get_Line,
+e.g.), or depend on previous input -- not typical of elab code. That's
+what I meant by "strange" above.  Normally elab code is 100% deterministic
+(given a particular Ada implementation).
+
+****************************************************************
+
+From: Robert Dewar
+Date: Friday, August 15, 2008  7:16 AM
+
+> Normally, I would, but in my book, elab failures are not "real" 
+> run-time errors
+> -- they are essentially equivalent to link-time errors, because unless 
+> you do something strange, they happen every time.  Even the most 
+> minimal regression test suite will catch them.
+
+It's not *so* strange to have elaboration code in a package body that
+is highly conditionalized ...
+
+****************************************************************
+
+From: Tucker Taft
+Date: Friday, August 15, 2008  9:47 AM
+
+I gave up on this approach both because others find it distasteful
+(e.g. Pascal), but also because it wasn't obvious that it really solved
+the interesting problems.  Randy pointed out that there would be various
+restrictions on what you could do in the generic, and that's pretty
+annoying.
+
+The post-private visible part seems very straightforward to me, since
+it mimics what things are like in the visible part of a child, and I
+know it accomplishes the goal of allowing essentially arbitrary
+instantiations of arbitrary generics inside the package spec where a
+private type is declared.  From my perspective, it only involves some
+relatively modest visibility fiddling.  It doesn't introduce any new
+overloading, freezing, elaboration, instantiation, or run-time semantics,
+all of which the partial instantiation process does, and all of which
+are inordinately subtle in most compilers.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Friday, August 15, 2008  9:52 AM
+
+> I gave up on this approach both because others find it distasteful 
+> (e.g. Pascal), but also because it wasn't obvious that it really 
+> solved the interesting problems.  Randy pointed out that there would 
+> be various restrictions on what you could do in the generic, and 
+> that's pretty annoying.
+
+Maybe it can't do everything, but it is SO much more palatable than the
+end private suggestion to me
+ 
+> The post-private visible part seems very straightforward to me, since 
+> it mimics what things are like in the visible part of a child, and I 
+> know it accomplishes the goal of allowing essentially arbitrary 
+> instantiations of arbitrary generics inside the package spec where a 
+> private type is declared.  From my perspective, it only involves some 
+> relatively modest visibility fiddling.  It doesn't introduce any new 
+> overloading, freezing, elaboration, instantiation, or run-time 
+> semantics, all of which the partial instantiation process does, and 
+> all of which are inordinately subtle in most compilers.
+
+repeating myself (in response to Tuck repeating himself :-))
+
+I find the end private business to completely mess up the relationshiop between
+the public and private parts of a spec ...
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Friday, August 15, 2008 10:09 AM
+
+> Normally, I would, but in my book, elab failures are not "real" 
+> run-time errors
+> -- they are essentially equivalent to link-time errors, ...
+
+Well, let me back off a little.  I admit that compile-time errors are
+slightly better than link-time errors, and link-time errors are slightly
+better than elab-run-time errors.  But all three are vastly superior
+to run-time errors that escape into the hands of customers.
+
+****************************************************************
+
+From: Steve Baird
+Date: Friday, August 15, 2008  1:10 PM
+
+Ignoring the higher-level questions about whether deferred instance body
+elaboration is even a good idea, I have a question about how it might work.
+
+Should the elaboration check associated with instantiating a generic be
+performed when the instance body is elaborated, as opposed to when the
+instance spec is elaborated?
+
+I'm wondering about something like
+
+   with G1;
+   pragma Elaborate_All (G1);
+   package Pkg is
+     type T is private;
+     package I1 is new G1 (T);
+     package I2 is new I1.G2;
+   private
+     type T is ,,, ;
+   end Pkg;
+
+If, as a result of some yet-to-be-specified mechanism, we end up deferring
+the elaboration of both of the two instance bodies until after the completion
+of type T, then I don't think we want the second instance to fail an
+elaboration check because the body of I1.G2 wasn't yet elaborated at the
+point where I2 was declared (as opposed to the point at which I2's body
+is elaborated).
+
+For the sake of compatibility, it would probably be a good idea to grant
+an implementation permission to perform the check at the point of the instance
+declaration in the case where the instance body is to be elaborated immediately
+after the instance spec.
+
+I bring this up now because the difference in generality between the two
+approaches (deferred instance body elaboration and post-private visible parts)
+is a significant issue. If a particular deferred instance proposal were unable
+to handle the preceding example, then that should be considered in evaluating
+the proposal. The relative complexity of the two proposals (both for users
+and for implementers) is also an issue and this question illustrates another
+(small) bit of complexity associated with the deferred instance approach.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Friday, August 15, 2008  1:41 PM
+
+> For the sake of compatibility, it would probably be a good idea to 
+> grant an implementation permission to perform the check at the point 
+> of the instance declaration in the case where the instance body is to 
+> be elaborated immediately after the instance spec.
+
+It is always permissible to freeze an entity at an earlier point if this
+can be done.  I would certainly check to see whether the actuals are
+already frozen before deciding to defer the elaboration of the instance body.
+
+> I bring this up now because the difference in generality between the 
+> two approaches (deferred instance body elaboration and post-private 
+> visible parts) is a significant issue. If a particular deferred 
+> instance proposal were unable to handle the preceding example, then 
+> that should be considered in evaluating the proposal. The relative 
+> complexity of the two proposals (both for users and for implementers) 
+> is also an issue and this question illustrates another (small) bit of 
+> complexity associated with the deferred instance approach.
+
+I don't see any problem with deferred freezing in this example, and I don't
+see any out-of-place elaboration checks. In the absence of any  
+reference to entities declared in I1 or I2, both packages are frozen   
+(and their bodies inserted) after the full declaration of T. If an entity
+from I2 is referenced,  given that the instantiation mentions
+G2 this freezes I1, which freezes T. If this happens before the full view
+of T it is a static elaboration error reported to the user.
+
+****************************************************************
+
+From: Steve Baird
+Date: Friday, August 15, 2008  3:10 PM
+
+> I don't see any problem with deferred freezing in this example, and I 
+> don't see any out-of-place elaboration checks.
+
+Applying 3.11(13) to this example, we get a runtime check at the point
+of the (elaboration of the) declaration of package I2 that the body of
+the generic I1.G2 has been elaborated. If the body of I1 is not elaborated
+until after the (elaboration of the) completion of type T, then this
+check will fail because the elaboration of the body I1 certainly includes
+the elaboration of the body of I1.G2 (I'm assuming here that G2 is
+declared within G1; it is not a child unit. I'm also assuming that G2 has
+a body).
+
+Does this clarify things? I hope I'm not misunderstanding your point and
+then restating the obvious.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Friday, August 15, 2008  3:23 PM
+
+> Does this clarify things? I hope I'm not misunderstanding your point 
+> and then restating the obvious.
+
+Clearly as written this conflicts with the notion of delayed freezing. 
+3.11 (13) would have to be modified to indicate that the check takes
+place at the point the instance is frozen, because that is where the
+generic body is needed. Given that it mentions freezing, the rule should
+probably be moved to 13.14.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Friday, August 15, 2008  5:13 PM
+
+> Two proposals for dealing with this is written up in AI95-0359-1 and 
+> AI95-0359-2. (The file names are AI-00359.TXT and AI-10359.TXT, in 
+> case you've forgotten the weird encoding we used to use).
+
+There are actually four alternative versions of this AI.
+
+>...There's also a lot in
+> the minutes of the various meetings that discuss these proposals, and 
+>in the  !appendix. I really don't want to have to go over all of this 
+>same ground  again.
+
+Agreed.  We should all try to refrain from arguing before reading up on
+past history!  ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, August 15, 2008  5:25 PM
+
+> There are actually four alternative versions of this AI.
+
+Right, but the other two are really about the "partial instantiation" idea.
+My understanding was that Ed wanted to avoid that much extra syntax. In any
+case, that idea has it's own 05 AI - AI05-0074-1, where it sits, encased in
+amber, waiting to be rediscovered. ;-)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent