Version 1.4 of ais/ai-00204.txt

Unformatted version of ais/ai-00204.txt version 1.4
Other versions for file ais/ai-00204.txt

!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 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 99-02-02
Is it permitted to provide a package Interfaces.Fortran even if pragma convention Fortran is not supported? (No.)
!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.
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

!section B.5(00)
!subject interfaces.fortran must be absent, right?
!reference AARM-B.5
!from Samuel T. Gregory 98-03-19
!reference 1998-15830.a Samuel T. Gregory 1998-3-19>>
!discussion

Because of a lack of a FORTRAN compiler, and lack of (scheduled) time to
get FORTRAN unconstrained array parameters right before scheduling an
AVF, we were not going to claim to interface to FORTRAN, then someone
here typed in INTERFACES.FORTRAN and checked it into our runtime. Now,
instead of getting an error on the "with Interfaces.Fortran" lines of
CXB50042 and CXB50052, we get other errors later on.

Please confirm that INTERFACES.FORTRAN must actually be absent in order
for an implementation not to claim to interface to FORTRAN and not have
the FORTRAN acvc tests apply. Or tell us the real criteria.

Ivan's reasoning follows:

 - B.5(20) requires us to support convention FORTRAN for a
   FORTRAN-eligible type.
 - B.1(14-18) defines a FORTRAN-eligible type as one that either is, or
   has only components that are, FORTRAN-compatible.
 - B.1(13) says that a type is FORTRAN-compatible if it's declared in
   package INTERFACES.FORTRAN or it's defined to be FORTRAN-COMPATIBLE.
 - B.5(18) requires us to claim that the specified types (ie. all of them
   in INTERFACES.FORTRAN) are FORTRAN-compatible.

 - Ergo, if we provide INTERFACES.FORTRAN, then we must support
   convention FORTRAN for any type that is derived from, or has
   components of, any type within INTERFACES.FORTRAN.

 - But, if we don't provide INTERFACES.FORTRAN, then B.1(20) allows us to
   claim that we don't permit *any* FORTRAN-compatible type, and
   therefore, that there are *no* FORTRAN-eligible types in our
   implementation, and therefore, that B.5(20) is moot.

****************************************************************

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
do provide package Interface.Fortran, but they don't support actual linkages
to Fortran code.

The tests expect an implementation not fully supporting Fortran interfaces to
reject "with Interface.Fortran;"  In the past, we have had implementations do
that and have also had implementations that accept the entire program but fail
at link time (because no Fortran compiler is available).  Both behaviors have
been graded Not-Applicable.

We believe that rejecting the pragma (because of the undefined convention
Fortran) is a third way to handle this situation. Is this acceptable?


****************************************************************

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
write-up made clear whether or not the package Interface.Fortran implies
support for convention Fortran, and vice versa. (Of course, any such
result should apply to all language conventions).

****************************************************************

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.

****************************************************************

From: 	john barnes[SMTP:jgpb@JBINFO.DEMON.CO.UK]
Sent: 	Wednesday, February 03, 1999 3:13 AM
Subject: 	ai-204

 Clearly this is going to have to be discussed again.

 I don't have very strong feelings about this topic. I wrote the AI as directed
 by the meeting and as written up in the minutes. But I thought it would
 prompt further discussion. Robert's point that the conventions might be well
defined by some other standard even if only de facto rather than having to refer
to an actual compiler is a very good one. It's no doubt better to have the
conventions defined by a standard than by some wretched compiler.

But I think it's untidy and confusing to provide an interfaces package without
supporting the convention pragma and that was certainly strongly felt at the
meeting if I recall correctly. However, everyone wasn't present.

 John

****************************************************************

From: 	Erhard Ploedereder
Sent: 	Wednesday, February 03, 1999 6: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.

Bob:
> 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.

Robert:
> I find this completely wrong, it is extremely useful to have
> Interfaces.COBOL around even if there is no COBOL compiler around.

I think it is neither silly nor wrong, just badly worded. It should not
say "interfacing pragma" but rather "convention pragma".

Look at the comment that prompted this whole issue. Do we consider it to be
conformant, if somebody types in the package spec, provides some dummy Ada
bodies that in effect convert Ada to Ada, and that's it ??

This is in gross violation of RM B.2(1), B.5(2) and RM B.5(20), combined with
1.1.3(17). Put simply: "You are not allowed to provide a package with
the same name as the predefined one that doesn't do what the RM prescribes, in
this case that the types have Fortran convention representation."

Erhard

****************************************************************

From: 	Robert Dewar[SMTP:dewar@GNAT.COM]
Sent: 	Wednesday, February 03, 1999 7:27 AM
Subject: 	Re: AI-00204

<<I think it is neither silly nor wrong, just badly worded. It should not
say "interfacing pragma" but rather "convention pragma".
>>

Nope, that's wrong too.

Interfaces.COBOL is very useful even if you do not support pragma
Convention (COBOL, xxx).

Remember that Interfaces.COBOL is provided as part of the feature for
interfacing with COBOL, fine in this context of course you need the
pragmas.

But if you can't interface with COBOL, because there is no COBOL compiler,
then of course the RM does not force you to interface with COBOL!!!

However, you can still implement any or all of the relevant section to
provide useful facilities to a user, providing you implement them
correctly.

****************************************************************

From: 	Robert A Duff[SMTP:bobduff@WORLD.STD.COM]
Sent: 	Wednesday, February 03, 1999 10:02 AM
Subject: 	Re: AI-00204

I really think the ARG has no business modifying the RM unless there's a
good reason.  There's no support in the RM for this imagined
restriction.  Therefore, to apply such a restriction, the ARG should
first argue that there's some concrete benefit to users, which I haven't
seen.  I've seen John saying it seems untidy, and Erhard being outraged
at implementor laziness, which may well be true -- bit it's pretty
marginal.

- Bob

****************************************************************

From: 	Erhard Ploedereder[SMTP:ploedere@INFORMATIK.UNI-STUTTGART.DE]
Sent: 	Wednesday, February 03, 1999 10:59 AM
Subject: 	Re: ai-204

Robert writes:
> Obvoiously the COBOL interfaces package is VERY useful even if you do not
> support the [convention] pragma.

Hmmm. Interfaces.COBOL might be a special case. Let me replay your argument
in my words to check whether I got it....
Because Interfaces.COBOL has all these Display_Format operations, it's
useful even if B.4(51) ("each type in Interfaces.COBOL is COBOL-compatible")
is violated. For really interfacing with COBOL at a binary level, you
obviously need the support of the various pragmas, but for writing text
files matching COBOL-expectations, the package alone is enough and pretty
useful.

Is that it ?

(I looked at Interfaces.C, too. And there similar benefits would be much more
marginal (Is_Nul_Terminated might be useful) and, in my opinion, even
detrimental if used as a packaged way of unsafe programming,
c.f., Interfaces.C.Strings.
For Interfaces.Fortran the benefits are non-existent, since it lacks any
useful interfaces.

****************************************************************

From: 	Erhard Ploedereder[SMTP:ploedere@INFORMATIK.UNI-STUTTGART.DE]
Sent: 	Wednesday, February 03, 1999 11:21 AM
Subject: 	Re: AI-00204

> I really think the ARG has no business modifying the RM unless there's a
> good reason.  There's no support in the RM for this imagined
> restriction.

Well, it's a confirmation AI. We're not modifying the RM.

And RM B.2(1), B.5(2), B.5(18) [and analogous sentences for the other language
packages], combined with 1.1.3(17), are repeated and ample justification to
call this a !confirmation. How you can read these paragraphs and come to
a different conclusion is beyond my understanding, but I'm listening :-)

So, if Bob's and Robert's opinion carries, the AI would need to be rewritten
to be a binding interpretation, nullifying the Annex B paragraphs cited
above by saying that these types shall be ..., IF pragma Convention is
supported. I sure hope that at least that's a universally agreed requirement
or else these Interface packages become a complete joke.

****************************************************************


Questions? Ask the ACAA Technical Agent