(j3.2006) (SC22WG5.5452) [ukfortran] Response to TS ballot
Fri Feb 20 13:38:25 EST 2015
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.
>>> 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:
In an unspecified but valid state
Undefined but definable
Undefined and not definable
Please will you stop misrepresenting me?
More information about the J3