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

[Bill Long]

On 3/22/11 1:43 PM, David Muxworthy wrote:
>> 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.

There seems to be gathering consensus to make that change.

> 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.

I don't see the possibility of ambiguity in this case.  The standard 
already uses syntax tokens to mean different things in different contexts.


> 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.

I do see some mentions of TS in Clause 6, which need to be changed to 
TR. Thanks for pointing this out.   The project is for a TR.


> 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.
>

Actually, the main thrust of the TR is the opposite. It expands the 
class of Fortran arguments that can be passed to and from C.

>       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.
>

The primary accommodation of that nature is the added facilities for 
interacting with C formal parameters that are declared void *.   There 
was a specific request for this from the MPI community.

Cheers,
Bill



> David Muxworthy
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>

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