From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Oct 20 19:54:42 2017 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 59038358A2B; Fri, 20 Oct 2017 19:54:42 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id 09BED35872B for ; Fri, 20 Oct 2017 19:54:40 +0200 (CEST) Received: by mail-pf0-f177.google.com with SMTP id x7so12082041pfa.1 for ; Fri, 20 Oct 2017 10:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevelionel.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=fodHGcda2ADCbcZF0rhrFOg1ZG55eQnpmYu6wDiuTek=; b=LHsd0Gwcic8DuSVDxZQCWC05ufUpp8jamhgRuzIF+sM7PhIZUV622/qGIl0tGW9TrB 4ZkyMiVZemAH7ea7v4+97aWNXGRAFc4Sa2r9RKFv0wbquvhT9nOici6Uu/9ekojhL6aL qhAAMISK7B6oim3zRZxa5wDDFBHzZKAbYT3XE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fodHGcda2ADCbcZF0rhrFOg1ZG55eQnpmYu6wDiuTek=; b=DViUftqcQjagmEHyxTyW28C87nyU0KEqD/bORQPosf5bq25uttOa0O/vOdIH4YY9c6 EOL+mKpTl++PKFc0wCkixil/7L+yMWkDrFG9/f2UtuiJlat+dUhJKqNHrHZ6Eq3F+en+ KvaH0OW6XZawuZW79pAxuaPrn8ufaUVD6tNiovAjc6gYUWjIWgHX1q4krYy1+VFROPcd WA6H9wx6yaEMRVoiLw1jiob5XdKo2Zn2lFZFo0DsxFSY3WFPIlR68oaXjsjax8xnjv37 DCgTklpZUop1k/NRxeW2+Z91/A6Uz98Xk6lp2hvDwjdN/GDYuHAXat8GlJoKkPmycEwW wAfw== X-Gm-Message-State: AMCzsaWRp7yCh0zlmfKeZZD7CcyVWgyi0tIIru9u3xmIpieOL1nS2sI8 3wPhzTt+E1lUKJz0AkFKaoXK6GDX7rTOxUExM6rIsa6BLTQ= X-Google-Smtp-Source: ABhQp+QHJaOAo2SFBdbnIZcOWWByTeXCcxbgMC768yDYBP6lat2uvr2uIm3l3lNwukQe2s9H2MQLgv9JcKevo/zuWy0= X-Received: by 10.84.245.145 with SMTP id j17mr4664878pll.163.1508522078783; Fri, 20 Oct 2017 10:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.137.170 with HTTP; Fri, 20 Oct 2017 10:54:38 -0700 (PDT) X-Originating-IP: [23.107.59.77] From: Steve Lionel Date: Fri, 20 Oct 2017 10:54:38 -0700 Message-ID: Subject: Upcoming ballot issues To: WG5 Content-Type: multipart/alternative; boundary="089e082b811ca45f2d055bfe2abe" Sender: owner-sc22wg5@open-std.org Precedence: bulk --089e082b811ca45f2d055bfe2abe Content-Type: text/plain; charset="UTF-8" Dear WG5 members, At this week's J3 meeting, we developed responses to all 77 comments submitted for the second CD draft. Many of the responses resulted in papers being written and most of those resulted in changes to the text of the CD. N2143, which you should have received a link to, contains all the responses and links to the papers. In addition to comment responses, there were papers written in response to issues raised elsewhere. Among the edits there were three technical changes which require approval by WG5. I will soon be opening a WG5 eBallot on this (and two other questions - see below). The changes are summarized as follows: - 17-219 (http://j3-fortran.org/doc/meeting/214/17-219.txt) Add a requirement that the varible specified as the STAT= argument to MOVE_ALLOC and various ATOMIC intrinsic procedures have a minimum decimal exponent range of 4, to be consistent with other specifications of STAT=. - 17-228 (http://j3-fortran.org/doc/meeting/214/17-228.txt) Disallow a coarray or coindexed variable on the left side of an intrinsic assignment statement if it is an unallocated allocatble variable, so that automatic allocation does not occur here. This is an incompatibility with Fortran 2008, which did not prohibit this. - 17-250r2 (http://j3-fortran.org/doc/meeting/214/17-250r2.txt) In response to multiple comments, disallow coarrays of TEAM_TYPE, similar to the existing restrictions for C_PTR and C_FUNPTR, as the values of TEAM_TYPE variables are likely to be image-specific. Assuming that WG5 approves these technical changes, J3 believes that the revision is ready to become a DIS. The ballot will ask WG5 to approve this transition, which would meet the current development schedule. Thirdly, paper 17-193r1 (http://j3-fortran.org/doc/meeting/214/17-193r1.txt) is a proposal from the UK to change the informal name of the revision from Fortran 2015 to Fortran 2018. The paper captures some of the discussion J3 had on the topic. Note that we have "re-numbered" the language name three times in the past when the publication schedule significantly overshot the original plan. J3 held a straw vote on this but the results were inconclusive. A question about this will also be on the ballot. (The paper also captures the concensus that we should not fall into the same trap for the next standard, and should start calling it Fortran 202X (or "Fortran 2X") until publication time is in sight. I am very much in favor of this.) Steve Lionel -- . --089e082b811ca45f2d055bfe2abe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear WG5 members,

At this we= ek's J3 meeting, we developed responses to all 77 comments submitted fo= r the second CD draft. Many of the responses resulted in papers being writt= en and most of those resulted in changes to the text of the CD. N2143, whic= h you should have received a link to, contains all the responses and links = to the papers. In addition to comment responses, there were papers written = in response to issues raised elsewhere.

Among the = edits there were three technical changes which require approval by WG5. I w= ill soon be opening a WG5 eBallot on this (and two other questions - see be= low). The changes are summarized as follows:

- 17-= 219 (http://j3= -fortran.org/doc/meeting/214/17-219.txt) Add a requirement that the var= ible specified as the STAT=3D argument to MOVE_ALLOC and various ATOMIC int= rinsic procedures have a minimum decimal exponent range of 4, to be consist= ent with other specifications of STAT=3D.=C2=A0

- = 17-228 (http:/= /j3-fortran.org/doc/meeting/214/17-228.txt) Disallow a coarray or coind= exed variable on the left side of an intrinsic assignment statement if it i= s an unallocated allocatble variable, so that automatic allocation does not= occur here. This is an incompatibility with Fortran 2008, which did not pr= ohibit this.

- 17-250r2 (http://j3-fortran.org/doc/meeting/214= /17-250r2.txt) In response to multiple comments, disallow coarrays of T= EAM_TYPE, similar to the existing restrictions for C_PTR and C_FUNPTR, as t= he values of TEAM_TYPE variables are likely to be image-specific.

Assuming that WG5 approves these technical changes, J3 beli= eves that the revision is ready to become a DIS. The ballot will ask WG5 to= approve this transition, which would meet the current development schedule= .

Thirdly, paper 17-193r1 (http://j3-fortran.org/doc/meeting/2= 14/17-193r1.txt) is a proposal from the UK to change the informal name = of the revision from Fortran 2015 to Fortran 2018. The paper captures some = of the discussion J3 had on the topic. Note that we have "re-numbered&= quot; the language name three times in the past when the publication schedu= le significantly overshot the original plan. J3 held a straw vote on this b= ut the results were inconclusive. A question about this will also be on the= ballot. (The paper also captures the concensus that we should not fall int= o the same trap for the next standard, and should start calling it Fortran = 202X (or "Fortran 2X") until publication time is in sight. I am v= ery much in favor of this.)

Steve Lionel

--
.<= /div>
--089e082b811ca45f2d055bfe2abe--