(j3.2006) Alternative binding label without C interoperability?

[Cohen Malcolm]

I still don't see what the problem is with external procedures, since the 
same compiler is involved.

I don't even follow what the alleged problem is with module procedures 
either, since the same compiler is involved!

Just because one vendor's compiler is defective (no internal procedures) is 
Not In Any Way an indication that the language needs an extension, because 
the language Already Has Internal Procedures!  Why is any extension we come 
up with going to be implemented by a compiler that already has no intention 
of following the standard.

>> Without any such entity, there is no way the standard can specify this.
>
>I understand.   But in this case there is no companion processor, so there 
>ought not to be an issue.

Huh?  There is no companion processor, so there is no way to specify this in 
the standard!  There has to be some way a *conforming* program can detect if 
a processor has completely ignored the directive, or mangled the name in an 
interesting way, for the standard to have any effect.

>runtime rather than at compile time

Colour me even more confused, since binding labels have no effect at compile 
time (they do at link time).

>Without providing all the pertinent details...

...there is no way of discussing the matter ("pertinent" does not mean 
"irrelevant").

On the face of it it would seem that writing a module procedure with a 
BIND(NAME=) option would not require any less overheads or dependencies than 
writing an external procedure with a USE statement; that procedure still 
depends on the module whether the source code appears in the same file or 
not.  (It is certainly easy enough to put an external procedure in the same 
file too...)

Cheers,
-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.