(j3.2006) MPI usage problems in Fortran

[Lionel, Steve]

Bill Long wrote,

> > It seems oddly redundant to me to add a LANG= keyword to BIND where
> the
> > first "parameter" to BIND is already a language name.
> 
> The current bind(c) semantics just says to use the C calling
> conventions.  The routine itself may very well be written in Fortran -
> the usual case where you have a Fortran library that you want to make
> accessible to C programmers.  The bind(c) by itself makes no
> implication
> that the routine is written in C.  The intent of the lang="C"
specifier
> is to say the routine is, indeed, written in C.  This allows you to
> make
> rules for the interface that would have no semantics if the routine
> were
> written in Fortran.

Ok, I get that, though I have not seen anything proposed that can't be
done in Fortran already (with vendor extensions), and I have seen many
applications making use of various ways to "trick" the language into
doing things that are natural in C.  Unless there's a REALLY good reason
not to, I'd prefer to let Fortran programmers play too, if the semantics
can be properly defined.

> > I had earlier proposed to the MPI-3 list a VOID attribute that would
> be
> > allowed to appear only in an dummy argument declaration in an
> interface
> > body, but I was told that this approach had been rejected earlier by
> the
> > Fortran committee (or perhaps that it "would not fly").
> 
> Same issue as above. Without the lang= specifier, you have to assume
> the
> function is written in Fortran, and the VOID attribute would be usable
> there.  My initial impression is that adding an attribute to the
> Fortran
> base language that cannot be used in a Fortran program would be more
> disruptive that defining a specific derived type.  The later does not
> change anything in the base language syntax, and thus is easier to
> implement in the standard.
> 
> If you had a VOID attribute, what type declarations could it be used
> with?  What are the semantics?

I'd be perfectly happy to let VOID be usable from Fortran code.  We
already support this with our ATTRIBUTES NO_ARG_CHECK directive and we
make use of it in our implementation of ISO_C_BINDING (which contains a
fair bit of Fortran code.)

VOID could be used with any type declaration in a dummy argument
declaration, including POINTER and ALLOCATABLE arguments and
assumed-shape arrays.  The semantics are that the TKR match rule does
not apply to that dummy.  Other argument rules still apply.  

In the Intel implementation of NO_ARG_CHECK, it is not permitted in a
generic spec nor for a PURE or ELEMENTAL routine. We also limit
NO_ARG_CHECK to an INTERFACE block or a module procedure.

When used for a dummy argument in a Fortran routine, it would have no
effect on that routine in that it would use the argument as otherwise
declared.  VOID only affects interface matching rules.

We have many years of experience with NO_ARG_CHECK and it has not
created any difficulties in semantics or implementation.  

Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH