Re: Is Interfaces.Fortran Mandatory or Optional?

[bobduff@world.std.com (Robert A Duff)]

In article <3435292A.39C2@boeing.com>,
John Harbaugh  <johnh.s.harbaugh2@boeing.com> wrote:
>Robert A Duff wrote:
><snip> 
>> See B.2(12,13).  There's no requirement to support interface to any
>> particular language.  It would be silly -- suppose there's no Fortran
>> compiler on some machine.  Is the Ada compiler vendor supposed to write
>> a Fortran compiler?
>>
>B.2(12,13) is implementation advice, not a requirement.  It seems rather
>obscure to conclude that an implementation, by not following the advice,
>is free to provide any, some, or none of the children of Ada.

Yes, I agree it's not clear.  But what else could we do?  Surely we
can't require interface to COBOL on machines that have no COBOL
compiler.  Perhaps it would have been more honest to put Annex B in the
"Specialized Needs (ie optional) Annex" category.

>...  Too bad
>the RM is not a forthright in this matter as it is say in the
>dissallowal of decimal types.  

True, but some would instead say, "Too bad decimal types are optional."
;-)

>Besides, I thought the RM defined an interface to an ISO-conformant
>object module.

I don't know of any ISO-defined object module format.  As far as I can
tell, there are a bazillion "standard" object file formats, and another
bazillion calling conventions, and some machines and OS's support some,
and some machines and OS's support others.  Please tell me I'm wrong:
I'd love to see some standardization in this area, but surely it's not
easy: an interface to another language involves calling conventions, and
calling conventions depend on the machine architecture (eg how many
registers are there, and what sort of instructions are they allowed in
and so forth).

>...  This does not imply that the implementor provide
>other-language compilers.  Is it not the case that C++ was not included
>in Annex B because it is not yet an ISO standard?

That's part of it, but it's also the case that it's just hard to define
all the details.  We didn't define an interface to Common Lisp,
either...

>> See also AARM-B.5(17.a), which points out the exact issue you're asking
>> about.
>
>        17.a   Ramification:  The means by which the Complex type is
>provided in Interfaces.Fortran creates a dependence of
>Interfaces.Fortran on Numerics.Generic_Complex_Types (see G.1.1).  This
>dependence is intentional and unavoidable, if the Fortran-compatible
>Complex type is to be useful in Ada code without duplicating facilities
>defined elsewhere.
>
>You're right, this does capture the issue.  It does not, IMHO, resolve
>the issue.

OK, so what should we have done instead?  Require that compilers that
support interface-to-Fortran also support annex G?  No, that's overkill.
Require all Ada compilers to support interface to Fortran?  No, that
doesn't make sense if there's no Fortran compiler for that target.
(Remember, we could be talking about some embedded system, here.)
Require that interface-to-fortran be supported if there *is* a Fortran
compiler?  No, that makes no sense -- suppose I write an Ada compiler
for machine X, and there's no Fortran compiler, but then 6 months later
somebody writes a Fortran compiler.  Is my Ada compiler correct for 6
months, and then somehow magically becomes incorrect because somebody
(perhaps I've never heard of) wrote a Fortran compiler?  Does it matter
whether or not that Fortran compile is widely used?

Just what do you think the Ada standard ought to have said in this area?

>Gripeingly yours (and thanks for your response),

You're welcome, I'm sure.

- Bob