(j3.2006) (SC22WG5.5384) [ukfortran] Straw vote on draft DTS

[N.M. Maclaren]

> Please answer the following question "Is N2033 ready for forwarding to
> SC22 as the DTS?" in one of these ways.
> 
> 1) Yes.
> 2) Yes, but I recommend the following changes.
> 3) No, for the following reasons.
> 4) Abstain.

NO, for the following reasons.

Reason 1
--------

I agree with Robert Corbett and Malcolm Cohen about stalled images, but
believe that they have understated the issue.  The requirement is to
handle the 'knock-on' effect of image A failing, image B getting stuck
as a consequence, and image C then needing to interact with image C.  I
agree with the authors that the concept is essential if support is to be
provided for failed images, and that is one of the reasons that I have
consistently voted against the whole feature or abstained.

I have implemented error recovery in run-time systems, have used and
worked on it in several contexts, and know that I am not smart enough to
specify it for a language like Fortran.  Of the thousand or so language
and environment specifications I have seen, I have never seen one
specify this successfully, even for a single environment.  It might be
possible in Haskell, but Fortran is not Haskell.  From the lack of
convergence of these documents and the comments on the mailing list,
this TS seems to be failing in the ways that so many others have failed
before it.  It is doubtful that adding this facility takes "full account
of the state of the art" (see the ISO Directives).

I believe that there is no chance whatsoever that this issue can be
resolved, and WG5 still keep to the schedule agreed in Las Vegas (see
N2020 and N2024).  Indeed, I doubt that it could be done with even a
year's delay.  Solving this problem is not within the state of the art,
despite considerable efforts in a great many contexts over the past
half-century.

I believe that the whole feature of support for failing and stalled
images should be removed, possibly specified in another TS, and not
integrated until there is significant implementation and user experience
in a fairly wide variety of environments.

Reason 2
--------

Many or most of the comments in N2013 on events have still not been
addressed, nor have some of ones on atomics and collectives.  In
particular, there are assumptions of cross-facility coherence and
progress but no normative text requiring them - indeed, quite the
opposite.  It is doubtful that the current TS is "consistent, clear and
accurate" (see the ISO Directives).  This is extremely serious, as
adopting an inconsistent set of assumptions will make it almost
impossible to deliver the target specified in 1. Scope, paragraph 2,
even ignoring the problem of the schedule.

I do not believe that this issue is as intractable as the previous one,
because specifying data and control flow and progress are within "the
state of the art".  However, I am doubtful that the facilities in TS can
be implemented efficiently without special hardware or operating system
support, while still delivering the consistency and progress that seem
to be assumed.  However, even if there are no consistency problems to be
resolved, I do not believe that accepting these aspects of this TS is
compatible with keeping to the agreed schedule.

I believe that this area needs further clarity, even if not a polished
specification, before the TS should be accepted.  I am not repeating the
relevant comments in N2013, because there is little point - there has
been little relevant change to the drafts.


Regards,
Nick Maclaren.