CVS difference for ais/ai-00082.txt

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

--- ais/ai-00082.txt	1998/09/30 00:17:14	1.1
+++ ais/ai-00082.txt	1999/07/09 01:48:11	1.2
@@ -1,11 +1,12 @@
-!standard E.4      (20)                               96-02-06  AI95-00082/01
+!standard E.4      (20)                               99-07-08  AI95-00082/02
 !class binding interpretation 95-07-27
+!status Corrigendum 2000 99-07-08
 !status WG9 approved 95-06-14
 !status ARG approved (subject to editorial review) 10-0-0  95-11-01
 !status received 95-07-27
 !subject The PCS may be defined by the user.
 
-!summary 95-07-27
+!summary
 
 An implementation that conforms to Annex E, and that supports pragma
 Remote_Call_Interface (which is not required -- see E.2.3(20)) must
@@ -17,7 +18,7 @@
 to depend on special properties of one particular implementation of
 System.RPC, but must work for any correct implementation of System.RPC.
 
-!question 95-07-27
+!question
 
 A(4) says:
 
@@ -31,13 +32,13 @@
 May an implementation require that a particular version of System.RPC be
 used?  (No.)
 
-!recommendation 95-07-27
+!recommendation
 
 (See Summary.)
 
-!wording 95-07-27
+!wording
 
-!discussion 95-07-27
+!discussion
 
 The intent is that the PCS be implemented by the user, or by a third
 party vendor -- it need not be implemented by the Ada compiler vendor.
@@ -54,9 +55,24 @@
 
 Thus, it would be correct for a validation test to provide a PCS
 implementation, and require the implementation to use that PCS in tests.
+
+!corrigendum E.05(24)
+
+@dinsa
+The permission of the introduction to Annex A does not apply to the body or
+children of System.RPC. Specifically, an implementation shall not restrict the
+replacement of the body of System.RPC. An implementation shall not restrict
+the compilation of children of System.RPC.
+
+An implementation shall support remote subprogram calls using an implementation
+of System.RPC provided by the user.
+
+!ACATS test
 
-!appendix 95-08-19
+Tests CXE5002 and CXE5003 use this capability.
 
+!appendix
+
 !section E.4(20)
 !subject vendor-supplied PCS
 !reference RM95-E.4(20)
@@ -71,9 +87,6 @@
 somehow relies on it), or is the vendor required to use the ACVC-supplied
 PCS for certain ACVC tests?  (the latter?)
 
-
-
-
 ****************************************************************
 
 !section E.5(27)
@@ -176,7 +189,7 @@
 !discussion
 >   This question was raised at the Jun 8,9 1994 ACVC review meeting,
 > (not by me), but is forwarded here for tracking purposes.
-> 
+>
 >   If a vendor supplies a PCS, is the vendor allowed to use that PCS
 > for all ACVC testing (possibly because the vendor's code-generation
 > somehow relies on it), or is the vendor required to use the ACVC-supplied
@@ -201,7 +214,7 @@
 !discussion
 >   This question was raised at the Jun 8,9 1994 ACVC review meeting,
 > (not by me), but is forwarded here for tracking purposes.
-> 
+>
 >   If a vendor doesn't supply a body for System.RPC (as permitted
 > by E.5(27)), and doesn't allow replacement of System.RPC (as
 > permitted by A(4)) with an ACVC-supplied body, can this vendor
@@ -250,7 +263,7 @@
 
 >>   This question was raised at the Jun 8,9 1994 ACVC review meeting,
 >> (not by me), but is forwarded here for tracking purposes.
->> 
+>>
 >>   If a vendor supplies a PCS, is the vendor allowed to use that PCS
 >> for all ACVC testing (possibly because the vendor's code-generation
 >> somehow relies on it), or is the vendor required to use the ACVC-supplied
@@ -287,17 +300,17 @@
 
 > >>   This question was raised at the Jun 8,9 1994 ACVC review meeting,
 > >> (not by me), but is forwarded here for tracking purposes.
-> >> 
+> >>
 > >>   If a vendor supplies a PCS, is the vendor allowed to use that PCS
 > >> for all ACVC testing (possibly because the vendor's code-generation
 > >> somehow relies on it), or is the vendor required to use the ACVC-supplied
 > >> PCS for certain ACVC tests?  (the latter?)
-> 
+>
 > > The latter makes more sense to me.  The whole point of this part of the
 > > language design is to allow people to plug in their own, or third-party,
 > > versions of the PCS.  So the code-generation should not rely on some
 > > particular PCS.
-> 
+>
 > It is more accurate to say that the purpose of System.RPC is to allow
 > implementations to permit third-party versions of the PCS in the absence of an
 > implementation-provided PCS.
@@ -308,10 +321,10 @@
 forced to use the compiler vendor's own implementation of it.
 
 > > So the code-generation should not rely on some particular PCS.
-> 
+>
 > However, this should not be mandated by the ACVC tests. For example, child
 > packages of System.RPC are permitted by E.5(26) and may be referenced to
-> implement features of Annex E. 
+> implement features of Annex E.
 
 I don't agree.  Where does the RM allow such a dependence on features
 outside of System.RPC for standard Annex E capabilities?  The intent was
@@ -349,7 +362,7 @@
 !discussion
 
 > I don't agree.  Where does the RM allow such a dependence on features
-> outside of System.RPC for standard Annex E capabilities? 
+> outside of System.RPC for standard Annex E capabilities?
 
 The Annex neither allows nor disallows such a dependence.
 
@@ -376,7 +389,7 @@
 innovative implementations wishing to compete in the interchangeable PCS
 market will have a mode whereby they can be validated using the ACVC-supplied
 PCS. The important consideration is not to preclude an innovative
-implementation from validation. 
+implementation from validation.
 
 > Otherwise, the definition of the standard System.RPC interface
 > is a complete waste.
@@ -401,12 +414,12 @@
 
 > >   This question was raised at the Jun 8,9 1994 ACVC review meeting,
 > > (not by me), but is forwarded here for tracking purposes.
-> 
+>
 > >   If a vendor doesn't supply a body for System.RPC (as permitted
 > > by E.5(27)), and doesn't allow replacement of System.RPC (as
 > > permitted by A(4)) with an ACVC-supplied body, can this vendor
 > > validate Annex E?  (no?)
-> 
+>
 > Since support for the Remote_Call_Interface pragma is optional E.2.3(20), it
 > seems that an implementation may validate Annex E under the conditions cited
 > above.
@@ -471,13 +484,13 @@
 !discussion
 
 > > I don't agree.  Where does the RM allow such a dependence on features
-> > outside of System.RPC for standard Annex E capabilities? 
-> 
+> > outside of System.RPC for standard Annex E capabilities?
+>
 > The Annex neither allows nor disallows such a dependence.
-> 
+>
 > > Compare E.5(1) with E.5(26).  E.5(1) is a hard requirement to use the
 > > System.RPC interface to implement remote subprogram calls.
-> 
+>
 > E.5(1) states that a conforming implementation shall use the RPC interface; it
 > does not require that a conforming implementation shall only use the RPC
 > interface.
@@ -488,18 +501,18 @@
 I believe you are playing word games here by claiming that "shall use
 the RPC interface" means "may but need not use the RPC interface."
 What possible force does this requirement have if we allow
-compiler-generated stubs to have arbitrary dependence on 
+compiler-generated stubs to have arbitrary dependence on
 proprietary interfaces in order to implement RPC?
 
 > ...  I believe a compiler should be required to work
 > > with whatever kind of "null" PCS that accompanies the ACVC suite.
-> 
+>
 > This position may harm innovation by compiler implementations that provide a
 > PCS. It serves no purpose to enforce this perceived compliance. Presumably,
 > innovative implementations wishing to compete in the interchangeable PCS
 > market will have a mode whereby they can be validated using the ACVC-supplied
 > PCS. The important consideration is not to preclude an innovative
-> implementation from validation. 
+> implementation from validation.
 
 This does not harm innovation.  The E.5(1) requirement in my view is that
 the compiler must work using any conforming implementation of System.RPC.
@@ -544,7 +557,7 @@
 !discussion
 
 > ... and doesn't allow replacement of System.RPC (as
-> permitted by A(4)) with an ACVC-supplied body 
+> permitted by A(4)) with an ACVC-supplied body
 
 > A(4) should be interpreted as not applying to System.RPC -- clearly, the
 > vendor can't forbid replacement of System.RPC.
@@ -604,17 +617,17 @@
 !reference as: 95-5247.a Offer Pazy 95-7-29>>
 
 !discussion
- 
+
 > The Annex neither allows nor disallows such a dependence.
- 
+
 > E.5(1) states that a conforming implementation shall use the RPC interface
 > does not require that a conforming implementation shall only use the RPC
 > interface.
 
-I don't believe that this is a corerct reading of the words.  The annex 
-says: "Shall use the package to implement RPC".  We are not (yet) at the 
-stage of legally defending rules, but there is no confusion with respect to 
-the intention and the rules. I don't think that implying that such ambiguity 
+I don't believe that this is a corerct reading of the words.  The annex
+says: "Shall use the package to implement RPC".  We are not (yet) at the
+stage of legally defending rules, but there is no confusion with respect to
+the intention and the rules. I don't think that implying that such ambiguity
 exists is beneficial at this point.
 
 
@@ -623,32 +636,32 @@
 > the compiler/PCS implementor or the PCS implementor. If it is restricted t
 > the PCS implementor, then E.5(27) is somewhat difficult to interpret.
 
-On the contrary, if you say that the permission to add children is for the 
+On the contrary, if you say that the permission to add children is for the
 compiler vendor then it does not make sense for it not to provide a body.
-We did face a wording problem with the annex since we were talking about 
-potentially two entities, a compiler-vendor and a third-party (or a user), 
-but I belive thatthe rule is that "implementation" by itself is the 
-compilation system and when we mean otherwise, we say so.  For example, in 
+We did face a wording problem with the annex since we were talking about
+potentially two entities, a compiler-vendor and a third-party (or a user),
+but I belive thatthe rule is that "implementation" by itself is the
+compilation system and when we mean otherwise, we say so.  For example, in
 (26), we say "The PCS is allowed to have", not "the implementation is ..."
 
 
 > > I don't agree.  I believe a compiler should be required to work
 > > with whatever kind of "null" PCS that accompanies the ACVC suite.
-> 
+>
 > This position may harm innovation by compiler implementations that provide
 > PCS. It serves no purpose to enforce this perceived compliance. Presumably
 > innovative implementations wishing to compete in the interchangeable PCS
 > market will have a mode whereby they can be validated using the ACVC-suppl
 > PCS. The important consideration is not to preclude an innovative
-> implementation from validation. 
+> implementation from validation.
 
 But then again, this goes contrary to the whole motivation of the annex.
-The whole idea wa sthat we don't expect compiler vendors to be the *main* 
-force behind innovation, experimentation and rich support of PCSs.  If that 
-was the goal, we didn't have to have a PCS.  The compiler just provides a 
-mimimum support and the real comm work is expected to come from elsewhere.  
-This is where we shoudl ensure open interface and room for innovation.  Of 
-course, a compiler vendor may provide wonderful PCSs, but that was not the 
+The whole idea wa sthat we don't expect compiler vendors to be the *main*
+force behind innovation, experimentation and rich support of PCSs.  If that
+was the goal, we didn't have to have a PCS.  The compiler just provides a
+mimimum support and the real comm work is expected to come from elsewhere.
+This is where we shoudl ensure open interface and room for innovation.  Of
+course, a compiler vendor may provide wonderful PCSs, but that was not the
 motivation of the annex approach.
 
 
@@ -702,5 +715,28 @@
 advantage of what I consider is a legitimate implementation permission in
 E.5(26) from validation. Can we agree on this point?
 
+
+****************************************************************
+
+!from Randy Brukardt  99-7-8
+!discussion
+
+The discussion above makes it clear that wording is needed to disallow an
+implementation from depending on facilities outside of System.RPC for
+implementing the communication needed for remote subprogram calls. This
+very hard to word. I tried variations of:
+
+An implementation shall not use facilities other than those defined by
+System.RPC to implement remote subprogram calls.
+
+but this makes it sound like internal library routines (for marshalling,
+perhaps) cannot be used. Therefore, I settled on a straightforward statement
+of what must be supported:
+
+An implementation shall support remote subprogram calls using an implementation
+of System.RPC provided by the user.
+
+An implementation which cheats in a visible way would violate this; and any
+other "cheating" isn't our business, anyway.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent