(j3.2006) NAME= for internal procs

[Richard E Maine]

On Jan 9, 2007, at 11:07 PM, Aleksandar Donev wrote:

> Concerning UTI 103 (page 330) and whether NAME="" should be  
> required for
> interoperable internal procedures. I was under the impression that for
> PRIVATE module procedures that are interoperable we required  
> NAME="" to
> be specified. But looking at the document I cannot find support for  
> this
> recollection. What do we do about private interoperable procedures and
> binding labels?

I don't recall anything about requiring NAME= for interoperable  
private module procedures. This could, of course, be a failure of my  
recollection, but I also don't see any reason why it should be  
required. The existing rules look to me to work fine and be sensible.  
Unless someone actually finds such a rule, I would say that the  
interpretation is pretty clear - that there isn't one and there is  
inadequate reason to retroactively make such an incompatible change.

My personal inclination would be that if internal procedures are  
allowed to be interoperable, they should be like module procedures in  
this regard, not requiring the NAME=. Seems to me that the issues  
involved are similar and that there is no overwhelming need for a  
requirement. Yes, there are potential name conflicts if you have  
multiple internal procedures of the same name (with different hosts,  
of course). But requiring NAME= doesn't solve that, as there can  
still be the same kind of name conflict if the multiple internal  
procedures specify the same binding label using NAME=. The existing  
rules seem to me to cover all this just fine; the name conflicts in  
both cases illegal code, which could be fixed by changing some of the  
binding labels either by changing some of the procedure name (and  
thus the default binding labels), or by appropriate use of NAME=.

But the internal procedure case isn't a matter of retroactive change  
incompatible with a published standard. It seems more open to debate.  
Unless I've missed something, the above would be my position in such  
a debate, but it isn't as strong as what I'd say about private module  
procedures. For private module procedures, I'd argue that they  
shouldn't even be considered debatable (unless, again, I missed where  
the requirement is in the published f2003 standard).

-- 
Richard Maine                |  Good judgment comes from experience;
Richard.Maine at nasa.gov       |  experience comes from bad judgment.
                             |        -- Mark Twain