CVS difference for ais/ai-00204.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00204.txt

--- ais/ai-00204.txt	1999/02/08 23:00:58	1.5
+++ ais/ai-00204.txt	1999/09/24 20:31:22	1.6
@@ -1,56 +1,77 @@
-!standard B.5      (00)                               99-02-02  AI95-00204/01
-!class confirmation 98-03-27
+!standard B.5      (00)                               99-09-24  AI95-00204/02
+!class binding interpretation 99-09-24
 !status work item 99-02-02
 !status received 98-03-27
 !priority High
 !difficulty Medium
 !subject Interfaces.Fortran must be absent, right?
 
-!summary 99-02-02
+!summary
 
-Interface packages such as Interfaces.Fortran shall not be provided if
-the implementation does not support the interfacing pragma for that
+Interface packages such as Interfaces.Fortran may be provided independently of
+whether the implementation supports the interfacing pragma for that
 language. This applies also to other foreign languages including C and
 COBOL.
 
-!question 99-02-02
+!question
 
 Is it permitted to provide a package Interfaces.Fortran even if pragma
-convention Fortran is not supported?  (No.)
+convention Fortran is not supported?  (Yes.)
 
-!response 99-02-02
+!recommendation
 
-There are two reasons for interfacing to another language such as
-Fortran. One is to access data in the conventions of that language and
-the other is to call code written in that language. The pragma convention
-Fortran is necessary for interfacing to data and both the convention
-Fortran and the package Interfaces.Fortran are necessary for interfacing
-to code.
-
-Because it is useful to be able to access data without also accessing
-code (such as reading files containing Fortran multidimensional arrays)
-an implementation can claim conformance to the Annex for Fortran without
-providing the package Interfaces.Fortran. Indeed there might not be an
-implementation of Fortran for the same target as the Ada implementation.
+(See summary.)
+
+!wording
 
-This is confirmed by B.2(12) which says should and not shall thus
+Replace the first sentence of B.2(12) which states
 
 "For each implementation-defined convention identifier, there should be
 a child package of package Interfaces with the corresponding name."
 
-However, whether Interfaces.Fortran is present or not, the provider of
-the implementation must identify the Fortran compilers with which the
-conventions agree and there must be at least one such compiler.
+by
 
-In summary, an implementation can claim ability to interface to Fortran
-if and only if the pragma convention Fortran is supported. Moreover, if
-the pragma convention Fortran is supported then the package
-Interfaces.Fortran may be provided but not otherwise.
+"A child package of package Interfaces with the name of a convention may
+be provided irrespective of whether the convention is supported by the
+pragma Convention."
+
+!discussion
+
+There are two primary reasons for interfacing to another language such as
+Fortran. One is to access data in the conventions of that language and
+the other is to call code written in that language.
 
+Ada provides two techniques for such interfacing. One is the pragma
+convention with appropriate parameter and the other is the existence of
+packages such as Interfaces.Fortran.
+
+It is the intention that either or both of these techniques may be provided
+independently for a given language. Thus the package Interfaces.Fortran
+provides types that are sufficient for interfacing as stated by B.5(2)
+irrespective of whether the pragma Convention is supported for Fortran.
+
+This is in apparent contradiction to B.2(12) which seems to imply that an
+interface package can only be provided if the corresponding pragma
+Convention is supported.
+
 Similar rules apply to other foreign languages.
 
+!corrigendum B.02(12)
+
+@dprepl
+For each implementation-defined convention identifier, there should be
+a child package of package Interfaces with the corresponding name.
+@dby
+A child package of package Interfaces with the name of a convention may
+be provided irrespective of whether the convention is supported by the
+pragma Convention.
+
+!ACATS test
+
+This is a permission to do something, so it is untestable by itself. The
+underlying features are throughly tested by the ACATS.
 
-!appendix 99-02-02
+!appendix
 
 !section B.5(00)
 !subject interfaces.fortran must be absent, right?
@@ -561,11 +582,11 @@
 Sent: 	Thursday, February 04, 1999 5:16 PM
 
 Randy Brukardt wrote:
-> 
+>
 > >I am completely unable to read this restriction into the RM (and of course
 > >if it is there it is obviously wrong), but please restate your argument
 > >that this restriction is already there
-> 
+>
 > B.3(61) says that an implementation SHALL support pragma convention for
 > a C-eligible type. (Each of the other sections have similar language). B.1(14-17)
 > makes it clear that such types can be constructed from the types in the package.
@@ -574,7 +595,7 @@
 
 Well, I sort of hate to wade into this morass.  However,
 what B.3(61) says, in my view, is that to support *interfacing
-to C*, the implementation must support convention C.  B.3(1), 
+to C*, the implementation must support convention C.  B.3(1),
 similarly, indicates that to support *interfacing to C*,
 the implementation must provide the package Interfaces.C and
 its children.  Nowhere does it say that if the implementation
@@ -583,7 +604,7 @@
 pragma Convention C.
 
 For the Specialized Needs annexes, we clearly allow subset
-implementations, so long as the implementation does not claim 
+implementations, so long as the implementation does not claim
 to fully support the annex.
 
 I believe we have adopted this same attitude relative to Annex B
@@ -591,12 +612,12 @@
 implementations need not fully support interfacing to all languages.
 Nowhere do I see a requirement for an all or nothing support of
 interfacing to a particular language.
- 
+
 > ...
 > So, now I'm certain that this needs to be a Binding Interpretation (at least to
 > get to the Dewar/Duff position). Unless of course we solve Robert's
 > complaint by requiring Interfaces.COBOL of all implementations...
-> 
+>
 
 I agree we should make it clear that support for particular "foreign"
 languages is optional, and that the support may be partial support

Questions? Ask the ACAA Technical Agent