(j3.2006) NAME= for internal procs

[Bill Long]

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 
outcome.

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 
classes currently:

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 
makes sense.

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.

Cheers,
Bill


-- 
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