CVS difference for ais/ai-00204.txt
--- ais/ai-00204.txt 1999/01/29 20:11:42 1.2
+++ ais/ai-00204.txt 1999/02/03 01:09:12 1.3
@@ -1,21 +1,57 @@
-!standard B.5 (00) 98-03-27 AI95-00204/00
+!standard B.5 (00) 99-02-02 AI95-00204/01
!class confirmation 98-03-27
+!status work item 99-02-02
!status received 98-03-27
!priority High
!difficulty Medium
!subject Interfaces.Fortran must be absent, right?
-!summary 98-03-27
+!summary 99-02-02
+Interface packages such as Interfaces.Fortran shall not be provided if
+the implementation does not support the interfacing pragma for that
+language. This applies also to other foreign languages including C and
+COBOL.
-!question 98-03-27
+!question 99-02-02
+Is it permitted to provide a package Interfaces.Fortran even if pragma
+convention Fortran is not supported? (No.)
-!response 98-03-27
+!response 99-02-02
+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.
-!appendix 98-03-27
+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.
+This is confirmed by B.2(12) which says should and not shall thus
+
+"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.
+
+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.
+
+Similar rules apply to other foreign languages.
+
+
+!appendix 99-02-02
+
!section B.5(00)
!subject interfaces.fortran must be absent, right?
!reference AARM-B.5
@@ -56,9 +92,9 @@
****************************************************************
-From: Brashear, Phil
-Sent: Friday, January 29, 1999 7:34 AM
-Subject: Fortran support
+From: Brashear, Phil
+Sent: Friday, January 29, 1999 7:34 AM
+Subject: Fortran support
On tests CXB5004 and CXB5005, an implementation rejects the Import pragma
because they do not define convention Fortran. As shown by CXB5001..3, they
@@ -77,9 +113,9 @@
****************************************************************
-From: Brukardt, Randy
-Sent: Friday, January 29, 1999 1:33 PM
-Subject: Re: Fortran support
+From: Brukardt, Randy
+Sent: Friday, January 29, 1999 1:33 PM
+Subject: Re: Fortran support
The discussion of AI-00204 at the Paris meeting suggests that such an
implementation is not allowed. However, it would be best if the AI
@@ -89,3 +125,149 @@
****************************************************************
+From: Robert A Duff
+Sent: Tuesday, February 02, 1999 9:58 AM
+Subject: Re: AI-00204
+
+> Interface packages such as Interfaces.Fortran shall not be provided if
+> the implementation does not support the interfacing pragma for that
+> language. This applies also to other foreign languages including C and
+> COBOL.
+
+I think the ruling is silly. It's perfectly harmless to have "extra"
+Interfaces.* packages lying around. And there's nothing in the RM
+saying otherwise. First, Implementation Advice ("should" rules) don't
+count. Second, the Impl Advice quoted in the AI, B.2(12) doesn't say
+the same thing as the AI -- it says that if you support convention X,
+you *should* have a package Interfaces.X. Not the other way around.
+
+Note that the AI claims to be a "confirmation", so it ought to follow
+from the RM rules. Preferably in an "obvious" way! ;-)
+
+Whether such "extra" packages are useful or not is irrelevant. The ARG
+is not in the business of forbidding useless things. Such packages are
+harmless, and the RM doesn't forbid them. Therefore they're allowed.
+
+The only reason this came up is because some ACVC tests have both a
+"with Interfaces.Fortran" and also "pragma Convention(Fortran, ...)".
+The grading criteria say that if the implementation complains about
+the with-clause, that's OK, but if the implementation complains about
+the pragma, that's not OK.
+
+So we have a case of some test writer being slightly confused, and the
+ARG then making that into law, by sheer invention of rules.
+
+Some of our implementations currently violate this rule. It would be
+easy to fix -- we just have to delete the package Interfaces.Fortran.
+Or, more likely, save it away somewhere for when we ever get around to
+finishing the implementation of Fortran interfacing. Therefore, from a
+practical point of view, I don't much care which way this turns out.
+The reason I'm saying something about it is that I don't like the idea
+of test-driven language rulings (as opposed to RM-driven, or
+user-needs-driven).
+
+- Bob
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, February 02, 1999 7:16 AM
+Subject: Re: AI-00204
+
+<<Interface packages such as Interfaces.Fortran shall not be provided if
+the implementation does not support the interfacing pragma for that
+language. This applies also to other foreign languages including C and
+COBOL.
+>>
+
+I find this completely wrong, it is extremely useful to have
+Interfaces.COBOL around even if there is no COBOL compiler around.
+As I read the AI, it is written up with exactly the contrary view.
+
+
+<<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.
+>>
+
+It is that sentence that seems plain wrong, why does there have to be
+at least one such compiler around.
+
+I can't really speak for Fortran here, but for example, GNAT always
+provides Interfaces.COBOL using standard IBM data formats shared by
+many compilers.
+
+This is useful on ALL machines, including those with no COBOL compiler,
+since it allows an Ada program to read and process files generated by
+an IBM-compatible COBOL compiler.
+
+Perhaps I read the AI wrong, but certainly the summary and the above
+quoted sentence seem to come to exactly the wrong conclusion here.
+
+It is never helpful to force compilers to remove a useful feature for the
+sake of some theoretical, and in this case plain silly, formal reason.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 02, 1999 12:35 PM
+Subject: RE: AI-00204
+
+Robert commenting on the AI:
+
+<<Interface packages such as Interfaces.Fortran shall not be provided if
+the implementation does not support the interfacing pragma for that
+language. This applies also to other foreign languages including C and
+COBOL.
+>>
+
+I find this completely wrong, it is extremely useful to have
+Interfaces.COBOL around even if there is no COBOL compiler around.
+As I read the AI, it is written up with exactly the contrary view.
+
+Randy:
+
+Supporting the Interfacing pragma does not require that a compiler exist.
+Indeed, to properly support data representations, the convention name
+COBOL, Fortran, etc. HAS to be supported.
+
+If you know what compiler you are supporting, you can generate appropriate
+import/export code. You don't need to actually have a compiler.
+
+Back to Robert:
+
+<<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.
+>>
+
+It is that sentence that seems plain wrong, why does there have to be
+at least one such compiler around.
+
+I can't really speak for Fortran here, but for example, GNAT always
+provides Interfaces.COBOL using standard IBM data formats shared by
+many compilers.
+
+This is useful on ALL machines, including those with no COBOL compiler,
+since it allows an Ada program to read and process files generated by
+an IBM-compatible COBOL compiler.
+
+Randy says:
+
+I totally agree that no compiler should be allowed. I'm not so convinced
+about the laissez-faire approach to handling this. It means that a user
+cannot really depend on anything about interfacing (if X is supported,
+that tells us nothing about whether anything else works), and it makes
+interfacing untestable. (It would not be possible to fail the tests - they
+would always be not applicable.)
+
+In that case, I would rather withdraw the tests as of no value - the only
+value they would have is to an implementor testing their compiler
+in-house, and that is not the purpose of the ACATS.
+
+Therefore, I think we HAVE to have some rules as to what support
+is required if any support is.
+
+ Randy.
+
+****************************************************************
Questions? Ask the ACAA Technical Agent