From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Oct 10 04:25:17 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 54944356934; Wed, 10 Oct 2012 04:25:17 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id ACA043565BB for ; Wed, 10 Oct 2012 04:25:14 +0200 (CEST) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id q9A2P9Dq071682 for ; Wed, 10 Oct 2012 02:25:12 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: <1EF50EFBF6D84A4182C9E8861E3F44E1@Maru6> From: "Malcolm Cohen" To: "WG5" References: <20120913041344.6B9ED3568F1@www.open-std.org> In-Reply-To: <20120913041344.6B9ED3568F1@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4765) J3/12-nnn J3 interpretations letter ballot #26 after meeting 198 - due 12-Oct-2012 Date: Wed, 10 Oct 2012 11:25:10 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01CDA6D9.E899CCC0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01CDA6D9.E899CCC0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The following Fortran interpretations are being balloted: =20 Yes No Number Title =20 -Y- --- F08/0040 MOVE_ALLOC for coarrays -Y- --- F08/0074 Implicit type in BLOCK construct -N- --- F08/0075 Pointer function reference as variable in = assignment -N- --- F08/0076 Pointer function reference in READ -Y- --- F08/0077 Function references as variables in DATA statements -Y- --- F08/0078 Are the IEEE values +0 and -0 distinguished -Y- --- F08/0079 NAMELIST and type specification -Y- --- F08/0080 Array constructors with polymorphic values -Y- --- F08/0081 Deallocation error handling -Y- --- F08/0082 Generic identifier and dtv arguments =20 NO vote for F08/0075: =20 (Note that the edit is wrong =E2=80=93 missing =E2=80=9Clabel=E2=80=9D = after the second statement =E2=80=93 but that is not the reason for = voting NO.) =20 Even though a =E2=80=9C.ADDRESS.=E2=80=9D operator might look = =E2=80=9Ccool=E2=80=9D, I have come to the conclusion that allowing = operator syntex to denote variables is a mistake. The standard has = various restrictions on operators to reduce the ability to obfuscate = your code, e.g. arguments are required to be INTENT(IN). The purpose of = operator syntax was to allow user-defined algebra, not junk coding. =20 There is no functionality provided by this feature that is not = adequately served, with less obfuscation, by function reference syntax. =20 The correct fix for this interp is to acknowledge our mistake in = permitting this syntax to occur at all anywhere, and changing R602 and = C602 to =20 R602 variable is designator or function-reference =20 C602 (R602) function-reference shall have a data pointer result. =20 Note that a less extreme viewpoint would be to allow the operator syntax = except as the variable in an assignment statement (or READ statement). = That would be a better solution than the nitpicky syntax tweaks that are = the current proposed solutions to this interp and the next, but would = not be as consistent as disallowing this problematic syntax entirely. =20 NO vote for F08/0076: =20 This should also be fixed by removing this particular syntax (operators) = for the feature (pointer function reference as variable). Or at the = very least, removing it from the READ statement. =20 Cheers, --=20 ................................Malcolm Cohen, Nihon NAG, Tokyo. ------=_NextPart_000_00A9_01CDA6D9.E899CCC0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The=20 following Fortran interpretations are being = balloted:

 

Yes  No   = Number    =20 Title

 

-Y-  ---  F08/0040   MOVE_ALLOC = for=20 coarrays

-Y-  ---  F08/0074   Implicit = type in=20 BLOCK construct

-N-  ---  F08/0075   Pointer = function=20 reference as variable in assignment

-N-  ---  F08/0076   Pointer = function=20 reference in READ

-Y-  ---  F08/0077   Function = references=20 as variables in DATA statements

-Y-  ---  F08/0078   Are the = IEEE values=20 +0 and -0 distinguished

-Y-  ---  F08/0079   NAMELIST = and type=20 specification

-Y-  ---  F08/0080   Array = constructors=20 with polymorphic values

-Y-  ---  F08/0081   = Deallocation error=20 handling

-Y-  ---  F08/0082   Generic = identifier=20 and dtv arguments

 

NO vote for=20 F08/0075:

 

(Note that the = edit is wrong =E2=80=93=20 missing =E2=80=9Clabel=E2=80=9D after the second statement =E2=80=93 but = that is not the reason for=20 voting NO.)

 

Even though a = =E2=80=9C.ADDRESS.=E2=80=9D=20 operator might look =E2=80=9Ccool=E2=80=9D, I have come to the = conclusion that allowing operator=20 syntex to denote variables is a mistake.  The standard has various=20 restrictions on operators to reduce the ability to obfuscate your code, = e.g.=20 arguments are required to be INTENT(IN).  The purpose of operator = syntax=20 was to allow user-defined algebra, not junk coding.

 

There is no = functionality=20 provided by this feature that is not adequately served, with less = obfuscation,=20 by function reference syntax.

 

The correct fix = for this interp=20 is to acknowledge our mistake in permitting this syntax to occur at all=20 anywhere, and changing R602 and C602 to

 

R602 = variable=20 is designator or=20 function-reference

 

C602 (R602)=20 function-reference shall have a data pointer = result.

 

Note that a less = extreme=20 viewpoint would be to allow the operator syntax except as the variable = in an=20 assignment statement (or READ statement).  That would be a better = solution=20 than the nitpicky syntax tweaks that are the current proposed solutions = to this=20 interp and the next, but would not be as consistent as disallowing this=20 problematic syntax entirely.

 

NO vote for=20 F08/0076:

 

This should also = be fixed by=20 removing this particular syntax (operators) for the feature (pointer = function=20 reference as variable).  Or at the very least, removing it from the = READ=20 statement.

 

Cheers,

-- =
................................Malcolm=20 Cohen, Nihon NAG, Tokyo.

------=_NextPart_000_00A9_01CDA6D9.E899CCC0--