(j3.2006) NAME= for internal procs
Wed Jan 10 14:07:21 EST 2007
Aleksandar Donev wrote:
>We had long discussions about this on this list, and Bill may remember the
>outcome. The question we discussed was whether private module procedures
>should be allowed to have a binding label. I had thought, but it seems I am
>wrong, that we decided not to allow them to have binding labels.
At the risk of fanning old flames, this is how I recall the debate and
Camp 1: The "private" concept applies only to the name of an object.
Thus the name of a private module procedure is not accessible to a
program unit that used the module. However, this limited sense of the
meaning of private did not require that the procedure itself be
inaccessible to a C caller. Indeed, the module procedure might exist
explicitly to give a C caller access to information in the module while
its name is blocked out on the Fortran side. This camp advocated to
allow a module procedure, public or private, to have a binding label.
Camp 2: The "private" concept really applies to the object itself, and
the argument about names was just a technicality. Thus, a private
module procedure should not be accessible outside the module by any
means, including to a C caller. This camp argued to disallow a binding
label for a private module procedure.
From reading the current standard, it appears that Camp 1 prevailed.
This is the result I recall as well.
That said, I agree that the case of internal procedures is different
because of the host environment issues.
As far as which of Aleks' two choices is the preferred approach, I think
there is some logic to the version in the J3 paper. I see two general
1) Names of abstract interfaces, names of dummy procedure arguments, and
names of procedure pointers.
2) Names of external and module procedures.
The group in class 1 represent names that are not attached to any actual
procedure (as seen by the linker), so it is reasonable that they should
not have binding labels. This is, indeed, the set of excluded names in
the current standard.
The group in class 2 do have names (possibly mangled) that are seen by
the linker, so the ability to modify the name though a binding label
Internal procedures do result in actual code, so would intuitively be
part of class 2. Given that, the natural assumption in reading code
would be that bind(c) without a name= clause would result in a binding
label based on the internal procedure name. Singling this one case out
as different seems like an irregularity. Explicitly requiring the
name="" form removes the irregularity and, I think, would result in
fewer programming errors.
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3