(j3.2006) (SC22WG5.4416) [ukfortran] WG informal ballot

[David Muxworthy]

> Please answer the following question "Is N1845 ready for forwarding  
> to SC22
> as the PDTR?" 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.

1.  Reasons for negative vote
1.1 The document is self-evidently not ready for issue as a PDTR,
     containing as it does six explicitly unresolved items.
1.2 Given the reservations expressed in N1844 and in subsequent email
     discussion it appears that significant technical problems remain
     to be resolved.

     I would withdraw this objection if paragraph 7 of the Foreword
     were changed to state that the facilities described in the
     document were experimental and not necessarily to be incorporated
     in a future standard[1], or if the project schedule were to be
     extended to allow further consideration of the proposals.  This
     would also allow for addressing the concerns that implementation
     costs may be high relative to user benefits and that Fortran is
     losing some of the (relative) coherence and consistency gained in
     designing F90/95.  See also 5.1 below.

    [1] The definition of a Technical Specification allows for this.

2.  Comments on unresolved technical issues
2.1 UTIs 17 and 18: As a matter of principle any infringement that can
     be detected at compile time should be a constraint.
2.2 UTI 15:  I agree with Malcolm's point.

3.  Other comments
3.1 If it is decided in a future revision that Fortran should limit
     the range of values taken by variables, then '..' would be an
     obvious delimiter, as it is in Ada and Pascal.  The symbol '..'
     should not be used here unnecessarily.
3.2 I would welcome an assurance that the new language features do not
     cause hidden interactions with, or unacceptable costs for, existing
     facilities, independent of interoperability.

4.  Minor editorial points
4.1 The document refers to itself as both a TR and a TS.  It should
     choose one.
4.2 References to J3 should of course be removed before submission.
4.3 Subclause A.1.6 uses KIND=4 and KIND=8 without any corresponding
     description.  There should be a comment or the code should be
     generalized.

5. A contrary view
5.1 The original project specification, N1667, was to extend the
     functionality of passing Fortran arguments to C.  It was not to
     change the Fortran language to accommodate a wider range of C
     arguments passed to Fortran or to incorporate further C concepts
     into Fortran.  Clause 5 of this document would look out of place
     in a Fortran standard.  The material would be more appropriate in
     a stand-alone document for those who need to use these facilities.

     While certain programming techniques may be common in C, it does
     not necessarily follow that Fortran should be distorted in order
     to accommodate them, unless there is very strong user demand.

David Muxworthy