CVS difference for ais/ai-00204.txt

Differences between 1.2 and version 1.3
Log of other versions for file 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