J3/99-145

Date:     24 May 1999
To:       J3
From:     Richard Maine
Subject:  BINDNAME=

I propose that the BINDNAME= specifier be dropped from C interop.
This should be pretty easy to do edits for, although I haven't
yet done so.  Just search for all occurances of BINDNAME and remove
them and any attached discussion.  Since BINDNAME has no defined
meaning, it would be pretty hard for this change to have any
complicated side effects.

Starting with the next paragraph is an almost verbatim copy, with one
paragraph of elaboration of an email I sent to the x3j3 list in April.
It generated no discussion at all on the list; there were 2 private
email replies, both expressing concurrence with the idea of removing
BINDNAME=.

In entering the interop edits (98-118r1), I'm struck by the question
of what the BINDNAME= in a BIND(C) is actually going to achieve and
thus whether there is any point in having it.  Note that I'm
particularly talking about BINDNAME= as opposed to the NAME=.

We've heard some mention about the kinds of things that might be
done with it.  But in the end, the only normative thing the current
draft says is

  "The meaning of the expression following a BINDNAME= specifier
   is processor dependent."

Even the notes are pretty vague...too vague to give much hint.  We
have

   "A processor may permit a procedure defined by means of Fortran to
    be known by more than one binder name, if it needs to be
    referenced from more than one companion processor, each of which
    has a different way of transforming an external name to a binder
    name.  Use of the BINDNAME= specifier might be appropriate in
    such a circumstance.

    This is not the only possible meaning of the BINDNAME= specifier,
    nor is the processor required to ascribe such a meaning to the
    specifier."

This is all so vague that I conclude there is no way of portably using
it.  I don't see much point in defining the syntax at all if we are
going to say this little about what it does.  I don't see that this is
any more portable than just having the vendors add extra BIND
specifiers as vendor extensions if they like.

Note that the expression is required to be an initialization
expression, so you this doesn't really buy you any flexibility
compared to saying that the syntax for doing extra stuff is vendor
dependent - you have to make it right at compile time in
both cases.

Plus, the current specification invites confusion.  I predict lots
of vendors (and even more users) looking at BINDNAME= and asking
what it is supposed to do and how they should use it.  Yes the
proposed words answer the question.  But the answer ("the meaning is
processor dependent") is so useless as to just invite further
question.

I find it additionally confusing that, although the meaning of
BINDNAME is completely processor dependent, there are some pretty
specific and obscure restrictions on exactly what contexts it
can be applied in.  Some of those restrictions obviously have
something more specific in mind.  If the processor doesn't
happen to choose the same interpretation as these restrictions
must have had in mind, then some of the restrictions are going to
look pretty silly and incomprehensible.  For example, why is it that
we feel it appropriate to have a constraint (in 12.5.2.1) against
specifying BINDNAME for an interface body?  How do we know that
the processor wouldn't choose a meaning that makes sense in that
context?

Is this a feature that people are really asking for and would really
use?  If so, does specifying its syntax, but leaving the meaning
processor dependent, achieve anything more than allowing processors to
extend as needed (which they are already allowed to do)?

If there is a feeling that code should be able to compile on any
processor, even though it might not have the meaning intended, how
about the following idea.  Explicitly say that a processor may define
extra specifiers for BIND.  Also say that a processor shall be able to
diagnose the use of an unrecognized BIND specifier, but that its not a
fatal error.  (Yes, I know thats not the right standardese, but it
should communicate the idea).  I think this invitation to add extra
specifiers would be just as portable (that doesn't take much in this
case) and less confusing than saying that BINDNAME is a specifier, but
we won't say what it means.

The preceding para is an attempt to do "something" for what I'm
guessing might be the motivation for wanting BINDNAME.  But I'm
thinking the best option is just to drop BINDNAME= altogether.

--
Richard Maine
maine@altair.dfrc.nasa.gov