(j3.2006) (SC22WG5.5454) [ukfortran] Response to TS ballot

[Bill Long]

On Feb 20, 2015, at 12:38 PM, N.M. Maclaren <nmm1 at cam.ac.uk> wrote:

> On Feb 20 2015, Bill Long wrote:
>>>> 
>>>> No, for the reasons given in N2038, N2013 and other votes.  I need to
>>>> reiterate that neither response in N2039 even addresses my comments.  I
>>>> believe that incorporating the TS into the main standard will cause
>>>> serious harm to Fortran, because the (semantic) difficulties cannot be
>>>> resolved (let alone specified unambiguously) in the time available.
>>>> Indeed, it is not clear even that they ARE soluble, because this TS is
>>>> specifying a feature that is beyond the state of the art, and has been
>>>> for half a century.  I would be prepared to change my vote to abstain if
>>>> the decision to incorporate it were reversed.
>>>> 
>>>> Response
>>>> It is our belief that agreeing to delay to a later revision of the
>>>> Fortran standard would lead to several "no" votes.  Failure to
>>>> standardize a resilience capability before compilers implement F2015
>>>> would lead to vendors implementing incompatible schemes, hurting the
>>>> goal of code portability.
>>> 
>>> Whether or not the second statement is true, and it is extremely
>>> unclear whether it is, it is not a response to my objections.  I am
>>> asserting that the task is infeasible, for the reasons I gave.
>> 
>> There are differing opinions on whether "the task is infeasible". I tend 
>> to weight higher the opinions of the guys who will end up writing the 
>> compiler and runtime code.
> 
> Firstly, as I have told you before, I have written run-time systems that
> allowed recovery, call back to user code and continuation.  I have met
> (or even heard of) very, very few other people that have.  And, based
> on that and experience with projects that have tried to specify such
> recovery, I can tell you that writing a run-time system that recovers
> when possible is TRIVIAL by comparison to specifying the circumstances
> when recovery is possible and the state of the program following such
> recovery - let alone doing that in a system-indepdent fashion!
> 
> It is the task that WG5 is faced with that I regard as infeasible, and
> (as evidence) point out that it has been an important but unachievable
> requirement for half a century.  As I hope that we all know, specifying
> the syntax for a facility but leaving its semantics unclear does NOT
> help portability, as each system behaves differently.  For example,
> following a failure, exactly WHICH objects are:
>    Defined
>    In an unspecified but valid state
>    Undefined but definable
>    Undefined and not definable
> 
> Please will you stop misrepresenting me?
> 

Sorry, Nick.  I was mistaken in assuming that the ?infeasible? task was the compiler and runtime work.  I?m glad that we have a demonstration of success in that area. 

Did you provide documentation with your project?  (I?m guessing so.)  Based on that, any suggestions for our writing task would be most appreciated. 

In terms of ?specifying the circumstances when recovery is possible?,  I see two aspects.  One is whether there are syntax and semantics specified that allow the program to resume execution at a place that is not part of the normal execution sequence.  Second is whether the algorithm is such that it is possible to restart.   Our current position is that the second is entirely the programmer?s responsibility.  We only supply help with the first. 

The task of ?specifying the state of the program following such recovery? is more of a challenge.  It depends on how the programmer is trying to restart.  If, for example, the program includes checkpoints, the desired action after the END TEAM statement would be to branch to code that restored state from the most recent checkpoint and resume execution just after that checkpoint.  The method we?re supplying additional help for is to branch back to the beginning of the current CHANGE TEAM construct and re-execute it.   There are a lot of potential states for objects in the program.  Paper 15-138 is an attempt at describing what happens.  Suggestions for improvement are welcome.

Cheers,
Bill





> 
> Regards,
> Nick.
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101