CVS difference for ais/ai-00041.txt

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

--- ais/ai-00041.txt	2000/04/11 19:36:33	1.8
+++ ais/ai-00041.txt	2000/04/14 01:45:06	1.9
@@ -1,4 +1,4 @@
-!standard 08.03    (16)                               00-03-07  AI95-00041/12
+!standard 08.03    (16)                               00-04-12  AI95-00041/13
 !standard 08.03    (18)
 !standard 10.01.05 (07)
 !standard 12.03    (13)
@@ -18,15 +18,20 @@
 
 !summary
 
-Program unit pragmas within a generic unit and applying to the generic
+Library 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 rule of the pragma specifies the contrary.  The only language
-defined pragma with such a rule is pragma Inline.
+specific rule of the pragma specifies the contrary.
 
 If the user wants a library unit pragma without such a rule to apply to
 an instance, then that pragma must be repeated explicitly for the
 instance.
 
+The following Implementation Advice is added:
+Program unit pragmas that are not library-unit pragmas, when
+supported for a generic unit, should apply to all instances of the
+generic for which there is not an overriding pragma applied directly
+to the instance.
+
 !question
 
 Do program unit pragmas and in particular library unit pragmas within a
@@ -60,19 +65,27 @@
 repeated explicitly for the instance.
 
 A respective note to the user should be added to 10.1.5.
+
+The program unit pragma INLINE applies to all instances, based on an
+explicit semantic rule of the pragma. Since a ruling on the applicability
+of program unit pragmas affects only implementation-defined support of
+pragmas, an implementation advice should be added in 10.1.5 that, for
+program unit pragmas applied to generic units, the pragma should apply
+to all instances of the generic unit.
 
-The anomaly of pragma INLINE applying to all instances is based on an
-explicit semantic rule of the pragma. (It may be regarded by implementers as
-an example of how implementation-defined pragmas for generic units may well
-be explicitly specified to apply to all instances.)
 
 !wording
 
-See recommendation.
+(See recommendation.)
 
 !discussion
+
+An exegesis of the Reference Manual showed that a clear answer to the questions
+cannot be derived from the current standard. This exegesis is not reproduced for
+the Defect Report, but can be retrieved from the appendix of the working document
+AI-00041.
 
-Part I: The individual program unit pragmas
+An examination of the individual program unit pragmas follows.
 
 Some general observations:
 
@@ -92,9 +105,9 @@
    ARM 10.1.5(4).
 
 
-Before discussing the language rules, we examine the pragma semantics for
-all program unit pragmas and discuss whether or not the pragma should apply
-to the generic unit only or to all its instances as well.
+We now examine the pragma semantics for all program unit pragmas
+and discuss whether or not the pragma should apply to the generic unit
+only or to all its instances as well.
 
 
 Pragma Preelaborate:
@@ -190,7 +203,6 @@
 all instances of the generic unit.
 
 
-
 Pragmas Shared_Passive and Remote_Types:
 
 These pragmas impose the necessary restrictions to create a shared passive
@@ -270,6 +282,13 @@
 and, hence, its instances.)
 
 
+Pragma Inline:
+
+Pragma INLINE (historically) subscribes to the rule that it applies to all
+instances, when given for a generic subprogram.  Its application to all
+instances relies on explicitly stated semantics of the pragma; ARM 6.3.2(5).
+
+
 Pragmas Convention, Export, Import:
 
 The applicability of these program unit pragmas to generic units is left
@@ -277,209 +296,57 @@
 whichever semantics seem most appropriate. Since these pragmas are not
 library unit pragmas, inheritance of the pragma by instances of the generic
 unit does not have the detrimental effects shown earlier in this analysis.
-AI-00199 elaborates further on this issue.
-
-
-Pragma Inline:
-
-Pragma INLINE (historically) subscribes to the rule that it applies to all
-instances, when given for a generic subprogram.  Its application to all
-instances relies on explicitly stated semantics of the pragma; ARM 6.3.2(5).
+In fact, if the pragmas were to apply only to the generic unit and not to its
+instances, it would be difficult to associate any semantics with them. The
+most natural interpretation is therefore that the pragmas apply to all
+instances of the generic unit.
 
 
 
 This concludes the list of predefined program unit pragmas. We have seen
 that, in some cases, applicability of the pragma to all instances would be
-seriously detrimental. We have seen other cases, where applicability to all
-instances may be more convenient on occasion, but is neither absolutely
-necessary nor warrants a rule that a-priori precludes reusable generic units
-that can be instantiated in both restricted and unrestricted contexts.
-
-
-Part II: The Language Rules
-
-First, the relevant ARM paragraphs:
-
-(The elisions ".." omit text irrelevant for the question at hand.)
-
-12.3(11) provides the general rule for checking legality rules in generic
-instantiations. The following discussion deals with these legality rules.
-
-12.3(13) states: "The instance is a copy of the text of the template".
-12.3(14) continues: "The interpretation of each construct within a generic
-declaration .. is determined using the overloading rules when that generic
-declaration .. is compiled. In an instance, the interpretation of each
-(copied) construct is the same, except in the case of a name that denotes
-the generic_declaration ..; the corresponding name in the instance then
-denotes the corresponding copy of the denoted declaration."
-
-8.3(16,18) reaffirms this "current instance rule":
-"Each occurrence of a usage name denotes the declaration determined by its
-interpretation. It also denotes the view declared by its denoted
-declaration, except in the following cases: ...
-If a usage name appears within the declarative part of a generic_declaration
-.. and it denotes that same generic_declaration then it denotes the current
-instance of the generic unit (rather than the generic unit itself)."
-
-10.1.5(2) states: "A name given as the argument of a program unit pragma
-... shall resolve to denote the declaration of the immediately enclosing
-program unit (if any); the pragma applies to the denoted program unit. If
-there are no names given as arguments, the pragma applies to the immediately
-enclosing program unit."
-
-Finally, 10.1.5(7): "The name, if any, in a library unit pragma shall denote
-the declaration of a library unit."
-
-From 8.3(16) we conclude that a usage name denotes both the declaration AND
-the view declared by the denoted declaration.  The "current instance rule"
-applies only to the view, not to the denoted declaration, which is always the
-declaration of the generic unit.
-
-Interpreting 10.1.5(7) literally in the context of 8.3(16), we can conclude
-that its restriction does not apply to the instance PI, since the denoted
-generic declaration is a library unit. (Note that 10.1.5(7) refers to the
-declaration, not to the declared program unit.)  An instantiation at
-non-library level is therefore legal.
-
-However, 10.1.5(2) contradicts, at least in spirit, this interpretation,
-since it states "The pragma then applies to the denoted program unit" (which
-is the entity declared by the denoted declaration and hence subject to the
-"current instance rule"). (So, while the pragma would not prevent
-non-library instantiation, its effects would still apply to the current
-instance. This would create interesting questions, for example, for the
-semantics of a pragma Preelaborate applying to a locally declared instance.)
-
-Also, 12.3(14) confuses the issue further, as it states that the usage name
-denotes the copy of the denoted declaration (rather than the denoted
-declaration), thus leaning towards a uniform current instance rule.
-
-
-The situation is different for the instance QI (containing the pragma
-without arguments). Here, the current instance rule or denotation of a
-declaration by a name is irrelevant, since there is no name involved. We can
-only resort to 12.3(13,14), which regards the instance as a copy of the text
-of the template, where the interpretation of each (copied) construct is the
-same as in the template, while none of the exceptions stated in 12.3(14)
-applies to our case.  Here, one might conclude that the pragma applies only
-to the generic unit, since "the interpretation stays the same" in an
-instance.
-
-On the other hand, we can read 10.1.5(2):
-"If there are no names given as arguments, the pragma applies to the
-immediately enclosing program unit.", combine this with the notion that the
-instance is a copy of the template, and conclude that the (copied) pragma
-applies to this copied enclosing program unit, i.e. the instance.
-
-(Irrespective of such literal reading of the standard, we note that surely
- the semantics of a pragma without argument should not differ from the
- semantics of the pragma naming the unit explicitly.)
-
-Program unit pragmas applied to generic subprograms are not affected by the
-current instance rule, since perforce they occur outside the generic unit;
-ARM 10.1.5(4). Hence, neither 12.3(13,14) nor 8.6(16,18) apply.
-Consequently, such pragmas can not be interpreted as applying to instances
-of such subprograms on the basis on instantiation and name interpretation
-rules.
-Note, however, that pragma INLINE (historically) subscribes to the rule that
-it applies to all instances, when given for a generic subprogram.  Its
-application to all instances relies on explicitly stated semantics of the
-pragma; ARM 6.3.2(5). This creates a quite different situation from
-applicability of pragmas to instances due to general name interpretation
-rules.
-
-This short exegesis of the ARM shows that there is no clear answer found in
-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.
-  2. confirm the rule that the pragma applies only to the generic unit
-     itself.
-  3. define the most appropriate rule for each pragma.
-
-In any case, the effect of the pragma without argument should be the same
-as the pragma with argument, as the former is surely intended as a shorthand
-for the latter.
-
-Alternative 1: "pragmas in generic units apply to instances":
-
-Arguably, it would contribute to conceptual unity, if the "current instance
-rule" were uniformly applied to all usage names of a generic unit. This
-would avoid the very fine distinction between the declaration denoted by a
-usage name and the view declared by the denoted declaration. It would also
-avoid the difference in pragma effects compared to the INLINE pragma, even
-though these effects are achieved through two completely independent language
-rules (name interpretation vs. explicitly specified pragma semantics).
-
-However, such a rule also implies that generic units containing library unit
-pragmas cannot be instantiated other than as library units. (If local
-instantiations were legal, at least the semantics of pragma Preelaborate
-requiring elaboration of the unit prior to all non-preelaborated library
-units of the partition would be impossible to obey for such instances).
-
-The rule would further imply that instantiations violating the pragma are
-always illegal. Some aggravatingly undesirable consequences have been shown
-in the discussion of the individual pragmas.
-
-Finally, if the main objective were to create uniformity for pragmas
-applicable to generic packages and generic subprograms, an additional
-general rule would have to be added to the language that extends
-applicability of pragmas for generic subprograms to their instances.  This
-in turn is completely unacceptable, since, for example, it would prohibit
-local instantiations of Unchecked_Conversion.
-
-
-Alternative 2: "pragmas in generic units do not apply to their instances"
-
-Here, the user disadvantages cited above do not exist, since pragmatic
-information about the instances is to be specified on a case-by-case basis.
-
-The only identifiable disadvantage from a user perspective is that the
-user has to replicate the pragmas for each instance to which they ought
-to apply, which may well be true for the use of most such generics.
-
-The rules for pragmas on generic subprograms already imply this alternative,
-so that no changes are required in that respect.
-
-The anomaly of pragma INLINE applying to instances as well is based on an
-explicit semantic rule of the pragma rather than a general rule of the
-language (and hence not really an anomaly, merely a potential surprise).
-
-From an implementation perspective, Alternative 2 is a minor problem for
-those implementations that subscribe to the expansion model for implementing
-generics.  The "current instance rule" comes natural to such an expansion
-(due to its systematic replacement of bound names), while a rule that limits
-the effect of the pragma to the generic declaration only will require
-special processing.
-
-The usage aspects outlined above outweigh this minor complication for
-implementations.
-
-
-Alternative 3: Individual rules for each pragma
-
-We rejected this alternative to maintain some uniformity in the
-interpretation of pragmas.
-
-
-
-In the final analysis, alternative 2 appears to have the fewest
-disadvantages and presents a uniform general rule, while still allowing
-"overriding" special rules for program unit pragmas that are not library
-unit pragmas, as in the case of pragma Inline.
+seriously detrimental. We have seen other cases of library unit pragmas,
+where applicability to all instances may be more convenient on occasion, but
+is neither absolutely necessary nor warrants a rule that a-priori precludes
+reusable generic units that can be instantiated in both restricted and unrestricted
+contexts.
+
+Finally, we have seen that the existing language-defined program unit pragmas
+that are not library unit pragmas should apply to their instances. For the INLINE
+pragma, this rule is already explicitly stated. However, as this presently matters
+only in cases, where applicability of the pragma to generic units is
+implementation-defined, and one can equally well conceive of future
+language-defined or implementation-defined pragmas, where automatic
+applicability to instances would not be appropriate, we recommend to make
+such an inheritance of pragmas by instances merely implementation advice, not
+a general semantic rule.
+
+Although a program unit pragma on a generic should then generally be
+"inherited" by its instances, it might be overridden by a pragma applied
+directly to the instance, e.g., by a Convention or Export pragma.  This is
+analogous to the rule for inheriting representation items by a derived type
+from its parent type.  The inherited specification may be overridden
+by a direct specification on the derived type itself.
 
-
 !corrigendum 10.01.05(7)
 
 @dinsa
 Certain program unit pragmas are defined to be @i<library unit pragmas>. The
 name, if any, in a library unit pragma shall denote the declaration of a
 library unit.
-@dinst
+@dinss
 @i<@s8<Static Semantics>>
+
+A library unit pragma that applies to a generic unit does not apply to its
+instances, unless a specific rule for the pragma specifies the contrary.
+
+@i<@s8<Implementation Advice>>
 
-A program unit pragma that applies to a generic unit applies
-to an instance of the generic unless the instance has an overriding pragma.
+When applied to a generic unit, a program unit pragma that is not a library unit
+pragma should apply to each instance of the generic unit for which there is not
+an overriding pragma applied directly to the instance.
 
+
 !ACATS test
 
 Test(s) are needed. A C-Test should be constructed to check that
@@ -832,6 +699,104 @@
 
 ****************************************************************
 
+!section 13.9(3)
+!subject does pragma convention for a generic unit apply to instances?
+!reference AARM-13.9(3a), 13.11.2(3a)
+!from Jesper Jørgensen
+!reference 1998-15798.a Jesper Joergensen  1998-1-29>>
+!discussion
+
+The above mentioned paragraphs seem to imply that convention specified for a
+generic unit is "inherited" to all its instances. Such a rule sounds
+reasonable, but where is the proof in the reference manual?
+
+The same rule could apply for pragma export and perhaps also import. Is that
+the case?
+
+The closest I could get to an answer to this question is AI-00041 which
+unfortunately directly contradicts the above mentioned paragraphs by stating
+that pragma convention, export and import can't be applied to a generic unit. I
+think that AI-00041 is wrong on this!
+
+-- Jesper
+
++---------------------------------------------------------------------+
+|                                                                     |
+|           \_\_\_\_   \_\_\_\_    \_\_\_\_       \_                  |
+|            \_     \_  \_     \_  \_              \_                 |
+|             \_      \_ \_      \_ \_       \_\_\_ \_                |
+|              \_     \_  \_     \_  \_              \_               |
+|               \_\_\_\_   \_\_\_\_    \_\_\_\_       \_              |
+|                                                                     |
+|  Jesper Jørgensen                                                   |
+|  DDC-I A/S                            Phone:       +45 45 87 11 44  |
+|  Gl. Lundtoftevej 1 B                 Fax:         +45 45 87 22 17  |
+|  DK-2800 Lyngby, Denmark              Email:       jj@ddci.dk       |
++---------------------------------------------------------------------+
+
+****************************************************************
+
+!section 13.9(3)
+!subject does pragma convention for a generic unit apply to instances?
+!reference AARM-13.9(3a), 13.11.2(3a)
+!reference 1998-15798.a Jesper Jørgensen
+!from Tucker Taft 98-01-29
+!reference 1998-15799.a Tucker Taft 1998-1-29>>
+!discussion
+
+: The above mentioned paragraphs seem to imply that convention specified for a
+: generic unit is "inherited" to all its instances. Such a rule sounds
+: reasonable, but where is the proof in the reference manual?
+
+: The same rule could apply for pragma export and perhaps also import. Is that
+: the case?
+
+Yes, I believe that pragmas Convention, Import, and Export
+should all be inherited by the instances of a generic, just
+like pragma Inline.
+
+: The closest I could get to an answer to this question is AI-00041 which
+: unfortunately directly contradicts the above mentioned paragraphs by stating
+: that pragma convention, export and import can't be applied to a generic unit. I
+: think that AI-00041 is wrong on this!
+
+I agree with you.  Pragmas convention, export, and import can be
+applied to a generic.  For example, it makes perfect sense to
+apply pragma Import(Intrinsic, ...) to the generic function
+Ada.Unchecked_Conversion.  It is unlikely that there will be
+a body for this generic written in Ada, but instead its "body"
+will be built into the compiler.  Similarly, applying a pragma
+convention to a generic subprogram clearly indicates that instances
+should use the specified calling convention.  Finally, applying
+pragma Export to a generic implies that all instances should be
+externally callable, perhaps with a given specified External_Name.
+Specifying a link_name would be tricky, given that having multiple
+instances with the same Link_Name would cause ambiguity at
+link time.  However, External_Names could all be the same presuming
+the language to which the instances are being exported supports
+overloading (e.g. Java or C++).
+
+In general, I believe AI-00041 should only apply to library
+unit pragmas.  For program unit pragmas that are not library
+unit pragmas (i.e. pragmas Inline, Convention, Export, and Import)
+it makes perfect sense that all instances inherit the pragma.
+For library unit pragmas, it does not make as much sense for the
+instances to inherit the pragmas, mostly because there is no
+requirement that the instances end up being library units at all.
+
+: -- Jesper
+
+: |  Jesper Jørgensen                                                   |
+: |  DDC-I A/S                            Phone:       +45 45 87 11 44  |
+: |  Gl. Lundtoftevej 1 B                 Fax:         +45 45 87 22 17  |
+: |  DK-2800 Lyngby, Denmark            Email:       jj@ddci.dk       |
+
+--
+-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
+Intermetrics, Inc.  Burlington, MA  USA
+
+****************************************************************
+
 !from Randy Brukardt  99-10-07
 
 At the recent ARG meeting, it was pointed out that the proposed change
@@ -904,3 +869,186 @@
 reference absolute registers anyway, maybe for good reasons and maybe not.
 
 ****************************************************************
+
+!from Erhard Plödereder 2000-4-12
+
+I moved the language exegesis from the main body of the AI to this appendix,
+as it is not needed in the Defect Report.
+
+Part II: The Language Rules
+
+First, the relevant ARM paragraphs:
+
+(The elisions ".." omit text irrelevant for the question at hand.)
+
+12.3(11) provides the general rule for checking legality rules in generic
+instantiations. The following discussion deals with these legality rules.
+
+12.3(13) states: "The instance is a copy of the text of the template".
+12.3(14) continues: "The interpretation of each construct within a generic
+declaration .. is determined using the overloading rules when that generic
+declaration .. is compiled. In an instance, the interpretation of each
+(copied) construct is the same, except in the case of a name that denotes
+the generic_declaration ..; the corresponding name in the instance then
+denotes the corresponding copy of the denoted declaration."
+
+8.3(16,18) reaffirms this "current instance rule":
+"Each occurrence of a usage name denotes the declaration determined by its
+interpretation. It also denotes the view declared by its denoted
+declaration, except in the following cases: ...
+If a usage name appears within the declarative part of a generic_declaration
+.. and it denotes that same generic_declaration then it denotes the current
+instance of the generic unit (rather than the generic unit itself)."
+
+10.1.5(2) states: "A name given as the argument of a program unit pragma
+... shall resolve to denote the declaration of the immediately enclosing
+program unit (if any); the pragma applies to the denoted program unit. If
+there are no names given as arguments, the pragma applies to the immediately
+enclosing program unit."
+
+Finally, 10.1.5(7): "The name, if any, in a library unit pragma shall denote
+the declaration of a library unit."
+
+From 8.3(16) we conclude that a usage name denotes both the declaration AND
+the view declared by the denoted declaration.  The "current instance rule"
+applies only to the view, not to the denoted declaration, which is always the
+declaration of the generic unit.
+
+Interpreting 10.1.5(7) literally in the context of 8.3(16), we can conclude
+that its restriction does not apply to the instance PI, since the denoted
+generic declaration is a library unit. (Note that 10.1.5(7) refers to the
+declaration, not to the declared program unit.)  An instantiation at
+non-library level is therefore legal.
+
+However, 10.1.5(2) contradicts, at least in spirit, this interpretation,
+since it states "The pragma then applies to the denoted program unit" (which
+is the entity declared by the denoted declaration and hence subject to the
+"current instance rule"). (So, while the pragma would not prevent
+non-library instantiation, its effects would still apply to the current
+instance. This would create interesting questions, for example, for the
+semantics of a pragma Preelaborate applying to a locally declared instance.)
+
+Also, 12.3(14) confuses the issue further, as it states that the usage name
+denotes the copy of the denoted declaration (rather than the denoted
+declaration), thus leaning towards a uniform current instance rule.
+
+
+The situation is different for the instance QI (containing the pragma
+without arguments). Here, the current instance rule or denotation of a
+declaration by a name is irrelevant, since there is no name involved. We can
+only resort to 12.3(13,14), which regards the instance as a copy of the text
+of the template, where the interpretation of each (copied) construct is the
+same as in the template, while none of the exceptions stated in 12.3(14)
+applies to our case.  Here, one might conclude that the pragma applies only
+to the generic unit, since "the interpretation stays the same" in an
+instance.
+
+On the other hand, we can read 10.1.5(2):
+"If there are no names given as arguments, the pragma applies to the
+immediately enclosing program unit.", combine this with the notion that the
+instance is a copy of the template, and conclude that the (copied) pragma
+applies to this copied enclosing program unit, i.e. the instance.
+
+(Irrespective of such literal reading of the standard, we note that surely
+ the semantics of a pragma without argument should not differ from the
+ semantics of the pragma naming the unit explicitly.)
+
+Program unit pragmas applied to generic subprograms are not affected by the
+current instance rule, since perforce they occur outside the generic unit;
+ARM 10.1.5(4). Hence, neither 12.3(13,14) nor 8.6(16,18) apply.
+Consequently, such pragmas can not be interpreted as applying to instances
+of such subprograms on the basis on instantiation and name interpretation
+rules.
+Note, however, that pragma INLINE (historically) subscribes to the rule that
+it applies to all instances, when given for a generic subprogram.  Its
+application to all instances relies on explicitly stated semantics of the
+pragma; ARM 6.3.2(5). This creates a quite different situation from
+applicability of pragmas to instances due to general name interpretation
+rules.
+
+This short exegesis of the ARM shows that there is no clear answer found in
+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.
+  2. confirm the rule that the pragma applies only to the generic unit
+     itself.
+  3. define the most appropriate rule for each pragma.
+
+In any case, the effect of the pragma without argument should be the same
+as the pragma with argument, as the former is surely intended as a shorthand
+for the latter.
+
+Alternative 1: "pragmas in generic units apply to instances":
+
+Arguably, it would contribute to conceptual unity, if the "current instance
+rule" were uniformly applied to all usage names of a generic unit. This
+would avoid the very fine distinction between the declaration denoted by a
+usage name and the view declared by the denoted declaration. It would also
+avoid the difference in pragma effects compared to the INLINE pragma, even
+though these effects are achieved through two completely independent language
+rules (name interpretation vs. explicitly specified pragma semantics).
+
+However, such a rule also implies that generic units containing library unit
+pragmas cannot be instantiated other than as library units. (If local
+instantiations were legal, at least the semantics of pragma Preelaborate
+requiring elaboration of the unit prior to all non-preelaborated library
+units of the partition would be impossible to obey for such instances).
+
+The rule would further imply that instantiations violating the pragma are
+always illegal. Some aggravatingly undesirable consequences have been shown
+in the discussion of the individual pragmas.
+
+Finally, if the main objective were to create uniformity for pragmas
+applicable to generic packages and generic subprograms, an additional
+general rule would have to be added to the language that extends
+applicability of pragmas for generic subprograms to their instances.  This
+in turn is completely unacceptable, since, for example, it would prohibit
+local instantiations of Unchecked_Conversion.
+
+
+Alternative 2: "pragmas in generic units do not apply to their instances"
+
+Here, the user disadvantages cited above do not exist, since pragmatic
+information about the instances is to be specified on a case-by-case basis.
+
+The only identifiable disadvantage from a user perspective is that the
+user has to replicate the pragmas for each instance to which they ought
+to apply, which may well be true for the use of most such generics.
+
+The rules for pragmas on generic subprograms already imply this alternative,
+so that no changes are required in that respect.
+
+The anomaly of pragma INLINE applying to instances as well is based on an
+explicit semantic rule of the pragma rather than a general rule of the
+language (and hence not really an anomaly, merely a potential surprise).
+
+From an implementation perspective, Alternative 2 is a minor problem for
+those implementations that subscribe to the expansion model for implementing
+generics.  The "current instance rule" comes natural to such an expansion
+(due to its systematic replacement of bound names), while a rule that limits
+the effect of the pragma to the generic declaration only will require
+special processing.
+
+The usage aspects outlined above outweigh this minor complication for
+implementations.
+
+
+Alternative 3: Individual rules for each pragma
+
+We rejected this alternative to maintain some uniformity in the
+interpretation of pragmas.
+
+
+Alternative 4: "library unit pragmas do not apply to instances, but program
+unit pragmas do".
+
+This alternative is not nice from a language-lawyerly point of view, as the
+applicability of pragmas to instances should be based on a common semantic
+principle. However, pragmatically, it is the preferable choice. As the rules for
+pragmas in general are somewhat outside the syntactic and semantic principles
+of the language anyway, this alternative was chosen.
+
+****************************************************************
+
+

Questions? Ask the ACAA Technical Agent