[J3] [EXTERNAL] Re: Clarification on F18/017

Tue Jun 9 08:38:54 EDT 2020

While I am not completely unsympathetic to the “surprising behavior” concern,  this seems like a particularly odd case for that to be the entire meat of the argument.   There are many things in Fortran that would be surprising to C/C++ programmers.  (Non) short-circuiting of conditionals being the first one that comes to mind,  but I could rattle off half a dozen off the top of my head.   Those with more experience could probably rattle off dozens.

I suspect part of the unstated motivation here is that most/all implementations of FINAL had bugs for long after the feature was introduced.    Those of us trying to exploit the feature became accustomed to adding print statements in our FINAL procedures so that we could verify what was actually happening.   But at the end of the day the only 2 things I cared about were (1) that everything that should have been finalized was, in fact, finalized, and (2) nothing was finalized twice.

Now, with my limited experience of looking at C++ code, I don’t recall ever seeing an output statement in a destructor, and would generally only expect such as a debugging aid that would eventually be removed.    I would expect the same in quality Fortran code.   Unless you put in a print statement you cannot know the order of finalization.    So the famed C++ coder is only going to be surprised if they become suspicious of FINAL in the first place.

What is really needed to further the argument is a concrete example in which the undesired order will lead to a surprising (or incorrect) result _beyond_ merely the order being surprising.    E.g., some handle to a non Fortran resource is obliterated before the resource is properly released.

- Tom

On Jun 8, 2020, at 7:36 PM, Carlson, Neil via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

Steve wrote:
> > On 6/8/2020 6:40 PM, Ondřej Čertík via J3 wrote:

> To wit: what is wrong with the way F18/017 allows for different ordering
>of finalization and why is it wrong?

Neil just answered it here:

https://mailman.j3-fortran.org/pipermail/j3/2020-June/012131.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.j3-2Dfortran.org_pipermail_j3_2020-2DJune_012131.html&d=DwMFBA&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=EDCdNzkccJ25Co3sjWrr1HlJQ3_CoIFWfekFE1ulcLI&m=DraIzsPv3n7-Psa0JC7MFNEnV-Tr4deBewMlDflZibo&s=etJP80kSIf_5JOWro3eg2jaKphqqC_5NTjxhZxj0Xac&e=>

> I see no technical argument there.

Surprising behavior IS a technical argument.  The issue is accessibility.  We all approach something new with a set of expectations based on previous experiences and extrapolation.  There's no essential requirement that Fortran do something in a similar way to other languages, or even be consistent with itself. It could do things willy nilly if it wanted.  But avoiding surprising behavior makes the language and its use more accessible and is something that ought to be sought after unless there is a compelling reason to do otherwise.  Which leads me to ...

What is the technical justification for this Steve:

> How does it make good sense for A to be finalized after P when its sibling component B is finalized before merely because one is allocatable and one is not?

-Neil
________________________________
From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> on behalf of Steve Lionel via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Sent: Monday, June 8, 2020 4:52 PM
To: j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>
Cc: Steve Lionel
Subject: [EXTERNAL] Re: [J3] Clarification on F18/017

> On 6/8/2020 6:40 PM, Ondřej Čertík via J3 wrote:

To wit: what is wrong with the way F18/017 allows for different ordering
of finalization and why is it wrong?

Neil just answered it here:

https://mailman.j3-fortran.org/pipermail/j3/2020-June/012131.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.j3-2Dfortran.org_pipermail_j3_2020-2DJune_012131.html&d=DwMFBA&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=EDCdNzkccJ25Co3sjWrr1HlJQ3_CoIFWfekFE1ulcLI&m=DraIzsPv3n7-Psa0JC7MFNEnV-Tr4deBewMlDflZibo&s=etJP80kSIf_5JOWro3eg2jaKphqqC_5NTjxhZxj0Xac&e=>

I see no technical argument there.

Stev

Provide an example program that
breaks if the ordering CBPA is used so that we can better understand
your arguments.

That has been provided here:

https://github.com/j3-fortran/fortran_proposals/issues/146#issuecomment-589857885<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_j3-2Dfortran_fortran-5Fproposals_issues_146-23issuecomment-2D589857885&d=DwMFBA&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=EDCdNzkccJ25Co3sjWrr1HlJQ3_CoIFWfekFE1ulcLI&m=DraIzsPv3n7-Psa0JC7MFNEnV-Tr4deBewMlDflZibo&s=x4dDy5pWBXi1R9NHPfTOLXzjhr0Ub_ZWTTot7f01J5E&e=>

That particular program I think is not open source, so we cannot share it. Let me know if that description of the problem is not clear, and we can provide a minimal example.

A minimal example would be very helpful, to me at least. If that program needs to enforce a particular order, it should do its own deallocation of components rather than waiting for the later automatic deallocation. I view this as akin to list-directed I/O - when you leave details up to the implementation, you should not be surprised when it does things differently than you would have.
Even more helpful would be a suggestion of how the finalization rules should be changed to achieve the effect you desire. Please also note my earlier comments about interps needing to make the minimum possible change to address the problem.
Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200609/4aaec97f/attachment-0001.htm>