Version 1.5 of ais/ai-00077.txt

Unformatted version of ais/ai-00077.txt version 1.5
Other versions for file ais/ai-00077.txt

!standard 10.01.04 (03)          00-01-25 AI95-00077/04
!class confirmation 95-07-27
!status Response 2000 00-01-25
!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
!qualifier Clarification
!subject Separate compilation of generic bodies
!summary
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
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 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. 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
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.
!ACATS test
The ACATS test CA14023 checks that the note 10.1.4(10) is supported.
!appendix

!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

****************************************************************

Questions? Ask the ACAA Technical Agent