CVS difference for ais/ai-00041.txt

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

--- ais/ai-00041.txt	1998/09/30 00:17:09	1.1
+++ ais/ai-00041.txt	1999/06/26 01:11:13	1.2
@@ -1,10 +1,11 @@
-!standard 08.03    (16)                               98-04-01  AI95-00041/08
+!standard 08.03    (16)                               99-06-25  AI95-00041/09
 !standard 08.03    (18)
 !standard 10.01.05 (02)
 !standard 10.01.05 (07)
 !standard 12.03    (13)
 !standard 12.03    (14)
 !class binding interpretation 95-06-25
+!status Corrigendum 2000 99-05-24
 !status WG9 approved 96-12-07
 !status ARG approved 12-0-0  96-10-07
 !status ARG approved (subj. ed. rev., letter ballot was 12-0-0) 96-10-03
@@ -15,7 +16,7 @@
 !difficulty Hard
 !subject Program unit pragmas in generic units
 
-!summary 96-09-15
+!summary
 
 Program unit pragmas within a generic unit and applying to the generic
 unit itself do not apply to instances of the generic unit, unless a
@@ -26,7 +27,7 @@
 an instance, then that pragma must be repeated explicitly for the
 instance.
 
-!question 95-06-25
+!question
 
 Do program unit pragmas and in particular library unit pragmas within a
 generic unit and referring to the generic unit apply to all instances of the
@@ -46,7 +47,7 @@
 pragma Pure is a library unit pragma, are instantiations of P and Q illegal,
 if the resulting instances are not library units ?
 
-!recommendation 95-06-25
+!recommendation
 
 Program unit pragmas within a generic unit and applying to the generic unit
 itself do not apply to instances of the generic unit, unless a specific
@@ -71,11 +72,11 @@
 an example of how implementation-defined pragmas for generic units may well
 be explicitly specified to apply to all instances.)
 
-!wording 96-05-28
+!wording
 
 See recommendation.
 
-!discussion 96-09-15
+!discussion
 
 Part I: The individual program unit pragmas
 
@@ -87,14 +88,14 @@
    This may be cumbersome, but no language functionality is lost.
 
 2. If a pragma that applies to a generic unit were to apply to
-   all instances automatically, the user would lose the 
+   all instances automatically, the user would lose the
    capability of specifying a pragma that applies to the generic
    unit only.
-   Note that the user does not have the option of placing the 
-   pragma outside the generic package and thereby escape a 
-   "current instance rule" (discussed later) selectively, since 
-   such placement is not allowed for pragmas on generic packages; 
-   ARM 10.1.5(4). 
+   Note that the user does not have the option of placing the
+   pragma outside the generic package and thereby escape a
+   "current instance rule" (discussed later) selectively, since
+   such placement is not allowed for pragmas on generic packages;
+   ARM 10.1.5(4).
 
 
 Before discussing the language rules, we examine the pragma semantics for
@@ -105,7 +106,7 @@
 Pragma Preelaborate:
 
 Consider the following example:
- 
+
 with user_defined_function;
    generic
       ...
@@ -121,7 +122,7 @@
 non-preelaborated library units; i.e., to avoid the need for elaboration
 checks upon instantiations).
 
-Yet, if the pragma applies to the instances as well, they would all 
+Yet, if the pragma applies to the instances as well, they would all
 be illegal, since they are not preelaborable !
 
 The semantics of pragma Preelaborate can been regarded as an expression of
@@ -143,7 +144,7 @@
 
 Pragma Pure:
 
-Consider the following example: 
+Consider the following example:
   generic
       type T is private;
    package Q is
@@ -184,7 +185,7 @@
 
 Among others, any predefined or implementation-defined pure generic packages
 could not be instantiated in any non-pure context, which would be a quite
-devastating consequence. 
+devastating consequence.
 
 (A similar dilemma arises for all the other categorization pragmas when
 used (or not used) in reusable generic packages.)
@@ -411,7 +412,7 @@
 the ARM to the questions at hand. In interpreting the standard, we
 therefore can take three different routes:
   1. confirm the "current instance rule", i.e., the pragma applies
-     to all instances. 
+     to all instances.
   2. confirm the rule that the pragma applies only to the generic unit
      itself.
   3. define the most appropriate rule for each pragma.
@@ -478,7 +479,7 @@
 Alternative 3: Individual rules for each pragma
 
 We rejected this alternative to maintain some uniformity in the
-interpretation of pragmas. 
+interpretation of pragmas.
 
 
 
@@ -486,9 +487,77 @@
 disadvantages and presents a uniform general rule, while still allowing
 "overriding" special rules for individual pragmas, as in the case of pragma
 Inline.
+
+!corrigendum 10.01.05(2)
 
-!appendix 96-11-16
+@drepl
+Certain pragmas are defined to be @i<program unit pragmas>. A name given as
+the argument of a program unit pragma shall resolve to denote the
+declarations or renamings of one or more program units that occur immediately
+within the declarative region or @fa<compilation> in which the @fa<pragma> immediately
+occurs, or it shall resolve to denote the declaration of the immediately
+enclosing program unit (if any); the @fa<pragma> applies to the denoted program
+unit(s).  If there are no names given as arguments, the @fa<pragma> applies to the
+immediately enclosing program unit.
+@dby
+Certain pragmas are defined to be @i<program unit pragmas>. A name given as
+the argument of a program unit pragma shall resolve to denote the
+declarations or renamings of one or more program units that occur immediately
+within the declarative region or @fa<compilation> in which the @fa<pragma> immediately
+occurs, or it shall resolve to denote the declaration of the immediately
+enclosing program unit (if any); the @fa<pragma> applies to the denoted program
+unit(s).  If there are no names given as arguments, the @fa<pragma> applies to the
+immediately enclosing program unit. Program unit pragmas given within a
+generic unit and applying to the generic unit itself do not apply to
+instances of the generic unit, unless a specific semantic rule of the
+@fa<pragma> specifies the contrary.
+
+!corrigendum 10.01.05(9)
+
+@dinsa
+An implementation may place restrictions on configuration pragmas, so
+long as it allows them when the environment contains no @fa<library_items>
+other than those of the predefined environment.
+@dinst
+NOTE@hr
+To apply a program unit pragma to an instance, it must be specified
+for the instance. A program unit pragma in the generic unit usually
+does not apply to any instances.
+
+!corrigendum 12.03(14)
+
+@drepl
+The interpretation of each construct within a generic declaration or
+body is determined using the overloading rules when that generic declaration
+or body is compiled. In an instance, the interpretation of each (copied)
+construct is the same, except in the case of a name that denotes the
+@fa<generic_declaration> or some declaration within the generic unit;
+the corresponding name in the instance then denotes the corresponding copy
+of the denoted declaration. The overloading rules do not apply in the instance.
+@dby
+The interpretation of each construct within a generic declaration or
+body is determined using the overloading rules when that generic declaration
+or body is compiled. In an instance, the interpretation of each (copied)
+construct is the same, except in the case of a name that denotes the
+@fa<generic_declaration> or some declaration within the generic unit;
+in the first case, the corresponding name in the instance then also
+denotes the current instance (see 8.6), in the second case the
+corresponding name in the instance then denotes the corresponding
+copy of the denoted declaration. The overloading rules do not apply
+in the instance.
+
+!ACATS test
+
+Test(s) are needed. A C-Test should be constructed to check that
+Pure/Preelaborate in a generic do not prevent the generic from being
+instantiated in a nested location. A B-Test should be constructed to
+check that Pure/Preelaborate in a generic do not automatically
+make the instantiation Pure/Preelaboratable. For example, instantiate
+such a generic at library level, with into a Pure/Preelab unit,
+check that an error occurs.
 
+!appendix
+
 !section 12.3(14)
 !section 12.3(13)
 !section 10.1.5(3)
@@ -718,7 +787,7 @@
 general point of view. I think that the idea that a generic is not known to
 be OK until it is instantiated by its clients is flawed.  What's the point
 of developing generics if you can't rely on the clean compilation until to
-point when users start to instantiate it. Also, if I understand (?!) the 
+point when users start to instantiate it. Also, if I understand (?!) the
 issue
 correctly, for implementation that do not use the macro-expansion approach,
 this will represent a major problem, since after a generic unit has been
@@ -777,8 +846,8 @@
 *library* unit pragmas on a generic library unit apply to the
 generic *only*, and not automatically to its instances.  On the other hand,
 program unit pragmas which are *not* library unit pragmas should, by
-default, apply to all instances.  In both cases, this should just be a 
-default rule, subject to overriding by rules which are specific to a 
+default, apply to all instances.  In both cases, this should just be a
+default rule, subject to overriding by rules which are specific to a
 particular pragma.
 
 I think these general rules make sense because when talking about
@@ -805,10 +874,10 @@
 to take into account this message I got from Robert Dewar:
 
 > with Ada.Numerics.Generic_Elementary_Functions;
-> 
+>
 > package Ada.Numerics.Elementary_Functions is
 >   new Ada.Numerics.Generic_Elementary_Functions (Float);
-> 
+>
 > according to our undertanding of the ARG decision, this unit does NOT
 > inherit the pragma Pure from the generic package. Therefore it is not
 > pure. But surely it is meant to be Pure. We propose adding a Pure

Questions? Ask the ACAA Technical Agent