[J3] [EXTERNAL] Re: Paper 22-120r4 available

[Clune, Thomas L. (GSFC-6101)]

Hi Van,

My apologies – I’m not going to have the time to give your analyses the time they deserve prior to the plenary discussion this evening.   But subgroup will definitely discuss in detail at our next meeting.

Taking a short break now to address some of the issues you raised in this last message.

I would think that a SAVE’d variable in this case would be the same variable (as requirement F states).   Users may well be surprised by the consequences when your subroutine A and subroutine B interfere with each other, yes.   The same is true if they both called some subroutine that have a SAVE’d local variable in it .    All very good reasons to be very careful about using a SAVE’d variable in any context.

The storage association “headaches” should map directly onto the existing case where the template in your example is replaced by a MODULE Q that has a saved variable in it, and Q is USE’d from your subroutine’s A and B.   There is no storage association of X in Q (accessed in A) vs X in Q (accesed in B).  It is the _same_ X.    Similarly with the template.  For identical template parameters there is only a single X.  Full stop.

Sorry to be so rushed in my response,


  *   Tom

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Tuesday, March 8, 2022 at 1:51 PM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Van Snyder <van.snyder at sbcglobal.net>
Subject: [EXTERNAL] Re: [J3] Paper 22-120r4 available

On Tue, 2022-03-08 at 13:37 +0000, Clune, Thomas L. (GSFC-6101) via J3 wrote:
I have modified the paper to split the initial straw vote into 3 separate straw votes.  Allowing nuanced differences in the treatment of type-bound procedures, data components, and kind/length parameters.

There are serious problems with part F.

Not the least of the problems is the difficulty for processors. Even instantiations with identical actual template parameters within the same scoping unit imposes an unnecessary burden. Program author(s) can manage duplication by instantiating in modules.

If instantiations with identical actual template parameters in different scoping are the same entity, SAVE variables, either template variables or within template procedures, are problematic.

Suppose a template is instantiated with identical actual template parameters in subroutine A in module M and in subroutine B in module N.

Suppose the template produces a variable X that has the SAVE attribute.

Is that variable X in subroutine A in module M the same as variable X in subroutine B in module N, as if by storage association?

This would be undesirable. It's an interp tar baby that will cause storage-associated migraine headaches.

Don't do part F.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220309/fca486b1/attachment.htm>