!standard 10.01.04 (03) 96-11-16 AI95-00077/02 !class confirmation 95-07-27 !status WG9 approved 96-12-07 !status ARG Approved 6-1-2 96-10-07 !status work item 96-05-07 !status received 95-07-27 !priority Medium !difficulty Medium !subject Separate compilation of generic bodies !summary 95-07-27 The NOTE in 10.1.4(10), which says that separate compilation of generic bodies is required, is correct. This implies that an implementation must be capable of detecting legality errors in a compilation unit that instantiates a generic unit, without seeing the generic body. It does *not* imply that the compiler must generate code without seeing the generic body. !question 95-07-27 RM 10.1.4(3) states that the mechanisms for replacing compilation units within an environment are implementation defined. Is it intended that "mechanisms" also means "circumstances"? This seems to be partly contradicted by Note 7 in RM 10.1.4(10) which prevents automatic removal of units that instantiate a generic body being replaced. This Note however, does not seem to follow from any normative statement. RM 10.1.4(7) allows removal of compilation units that depend upon a given one, but nothing apparently prevents removal of compilation units that don't have such a dependency. !response 95-07-27 10.1.4(3) is simply saying that the "commands" or "mouse clicks" that the user gives to perform various actions are implementation defined. It is not intended as a permission for the implementation to arbitrarily remove compilation units from the environment. 10.1.4(7) says when compilation units can be automatically removed, and this list is intended to be complete. An implementation may, of course, have additional commands for removing compilation units, or performing any other actions on the environment. !appendix 96-05-07 !section 10.01.04(03) !subject can implementation choose when to remove units from environment? !reference RM95-10.01.04(03) !reference RM95-10.01.04(10) !from Dan Eilers 95-07-17 !reference as: 95-5225.a Dan Eilers 95-7-17>> !discussion RM 10.1.4(3) states that the mechanisms for replacing compilation units within an environment are implementation defined. Is it intended that "mechanisms" also means "circumstances"? This seems to be partly contradicted by Note 7 in RM 10.1.4(10) which prevents automatic removal of units that instantiate a generic body being replaced. This Note however, does not seem to be follow from any normative statement. RM 10.1.4(7) allows removal of compilation units that depend upon a given one, but nothing apparently prevents removal of compilation units that don't have such a dependency. **************************************************************** !section 10.01.04(03) !subject Separate compilation of generic bodies !reference AI95-00077 !reference RM95-10.01.04(03) !reference RM95-10.01.04(10) !from Dan Eilers 95-10-28 !reference 95-5369.a Dan Eilers 95-10-28>> !discussion > This implies that an implementation > must be capable of detecting legality errors in a compilation unit that > instantiates a generic unit, without seeing the generic body. It does > *not* imply that the compiler must generate code without seeing the > generic body. If generating code isn't required to be automatic with compilation, is it required to be automatic with linking? If not, there doesn't seem to be much user benefit to requiring a second compile to get code generation vs. requiring a second compile because the generic body wasn't available the first time. -- Dan Eilers **************************************************************** !section 10.01.04(03) !subject Separate compilation of generic bodies !reference RM95-10.01.04(03) !reference RM95-10.01.04(10) !reference AI95-00077 !reference 95-5369.a Dan Eilers 95-10-28 !from Bob Duff !reference 96-5454.a Robert A Duff 96-4-8>> !discussion Draft version of AI-77 says: > > This implies that an implementation > > must be capable of detecting legality errors in a compilation unit that > > instantiates a generic unit, without seeing the generic body. It does > > *not* imply that the compiler must generate code without seeing the > > generic body. Dan Eilers says: > If generating code isn't required to be automatic with compilation, > is it required to be automatic with linking? No. The standard has nothing whatsoever to say about when code is generated. A valid implementation could general all code at link time, or could sometimes generate code at run time, or could be purely interpretive. As far as the Standard is concerned, the output of the compiler is simply an answer to the question "Is this legal?" > If not, there doesn't seem to be much user benefit to requiring a second > compile to get code generation vs. requiring a second compile because the > generic body wasn't available the first time. I don't understand. The two phrases connect be "vs." above seem essentially the same to me. In any case, the Standard doesn't address the issue of code generation. One has to presume that compiler writers will generate code in whatever way is most useful to their customers. The Standard just says that you have to be able to check incomplete programs for legality, including the case where the generic body is missing. Whether or not this is *important* functionality, I don't know, but it is at least potentially useful, and the Standard does require that support. - Bob **************************************************************** !section 10.01.04(03) !subject Separate compilation of generic bodies !reference RM95-10.01.04(03) !reference RM95-10.01.04(10) !reference AI95-00077 !reference 95-5369.a Dan Eilers 95-10-28 !reference 96-5454.a Robert A Duff 96-4-8 !from Dan Eilers !reference 96-5508.a Dan Eilers 96-4-23>> !discussion > Dan Eilers says: > > > If generating code isn't required to be automatic with compilation, > > is it required to be automatic with linking? > > No. The standard has nothing whatsoever to say about when code is > generated. A valid implementation could general all code at link time, > or could sometimes generate code at run time, or could be purely > interpretive. As far as the Standard is concerned, the output of the > compiler is simply an answer to the question "Is this legal?" > > > If not, there doesn't seem to be much user benefit to requiring a second > > compile to get code generation vs. requiring a second compile because the > > generic body wasn't available the first time. > > I don't understand. The two phrases connect be "vs." above seem > essentially the same to me. Let me rephrase my question: Is it allowable to reject a program at link time because an instantiation was compiled before its body (possibly preventing code generation needed for the link)? Or is the linker required to automatically do whatever is necessary to generate the code for the instantiation (e.g. recompile the instantiation), so that the program can be successfully linked? If the former, then there doesn't seem much user benefit to getting a link-time error rather than a compile-time error (as is typically the case in Ada83). If the latter, then this is really quite a significant undocumented change from Ada83. -- Dan Eilers **************************************************************** !section 10.01.04(03) !subject Separate compilation of generic bodies !reference RM95-10.01.04(03) !reference RM95-10.01.04(10) !reference AARM-10.01.04(10.a) !reference AI95-00077 !reference 95-5369.a Dan Eilers 95-10-28 !reference 96-5454.a Robert A Duff 96-4-8 !reference 96-5508.a Dan Eilers 96-5-23 !from Tucker Taft 96-04-23 !reference 96-5509.a Tucker Taft 96-4-23>> !discussion > ... > Let me rephrase my question: > > Is it allowable to reject a program at link time because an > instantiation was compiled before its body (possibly preventing > code generation needed for the link)? Or is the linker required > to automatically do whatever is necessary to generate the code for > the instantiation (e.g. recompile the instantiation), so that the > program can be successfully linked? > > If the former, then there doesn't seem much user benefit to > getting a link-time error rather than a compile-time error > (as is typically the case in Ada83). If the latter, then > this is really quite a significant undocumented change from > Ada83. In the AARM, at 10.1.4(10.a), it indicates the intent of the standard, namely that automatic instantiation can be performed at link-time, if necessary. Nevertheless, I doubt that there are enough normative words in the RM to force this to be accomplished in some specific, testable way. Presumably most vendors intend to provide some kind of automatic recompilation facility, and this is basically implying that automatic instantiation should fit into that facility, however it is invoked. I'm not sure what you mean by "undocumented." Practically all of Chapter 10 was rewritten for 9X. The words in 10.1.4(10,10.a) appeared first in about September 1993 (version 4.0). We didn't identify individual changes in 10.1.4, since the entire model was different. We did try to highlight various ramifications via AARM annotations. > -- Dan Eilers -Tuck **************************************************************** !section 10.01.04(03) !subject Separate compilation of generic bodies !reference RM95-10.01.04(03) !reference RM95-10.01.04(10) !reference AARM-10.01.04(10.a) !reference AI95-00077 !reference 95-5369.a Dan Eilers 95-10-28 !reference 96-5454.a Robert A Duff 96-4-8 !reference 96-5508.a Dan Eilers 96-5-23 !from Dan Eilers 96-04-23 !reference 96-5510.a Dan Eilers 96-4-23>> !discussion > I'm not sure what you mean by "undocumented." Practically all of > Chapter 10 was rewritten for 9X. The words in 10.1.4(10,10.a) appeared > first in about September 1993 (version 4.0). We didn't identify > individual changes in 10.1.4, since the entire model was different. > We did try to highlight various ramifications via AARM annotations. > > -Tuck I meant that it wasn't documented as being something that changed from Ada83 (in AARM or chg83.doc). -- Dan ****************************************************************