obsolescent forall

[Dan Nagle]

Hi,

These's a proposal before WG5 to make forall obsolescent in f15.

Should that happen? (I'm asking for opinions -- if thers's
a strong enough negative reaction I'll oppose doing so.)

This will (largely) be decided during the June 23-27 meeting,
in Las Vegas. See http://www.j3-fortran.org for meeting details.

--
Cheers!

Dan Nagle

[ftin...@gmail.com]

Hi,

Having worked some years on legacy applications, I've not seen
forall in any code. Also, I've been working on updating/enhancing
old Fortran code (and on rather new one...), and I've not found
any usage to forall (i.e. some code which would be enhanced by
using forall). Maybe my experience is too short, or even
useless, but...

... my two cents...

Fernando.

[Izaak B Beekman]

I feel strongly about keeping `where` but, as far as I can tell, `do
concurrent` has all of the syntactic conveniences as `forall` with
semantics that are much easier for compilers to optimize. I have used
`forall` in the past, and then been puzzled about performance
decreases. It was computationally expressive and convenient for doing
things like finite differences, but slow. So long as there is decent
compiler support for `do concurrent` by the time the next standard is
released, I have no problem with making `forall` obsolescent.
--
-Zaak

[Ron Shepard]

In article <lmkrsl$ki9$1...@dont-email.me>,

This comment makes the mistake of conflating a vector construct
(FORALL) with a looping construct (DO CONCURRENT).

If FORALL is made obsolescent, then how does one write a vector
expression in terms of its subscripts where the expression needs to
be completely evaluated before assignment?

$.02 -Ron Shepard

[N.H. Veldhuijzen]

I strongly agree with Ron Shepard.

Niels H. Veldhuijzen

Ron Shepard schreef op 3-6-2014 18:57:

[Tim Prince]

The case I know of "where" forall isn't equivalent to a sequence of do
concurrent (each terminating at the point of required full evaluation)
would be in the case of a mask which involves arrays which are written
over. For that case, the mask might be saved explicitly in a local
array (which might have been done implicitly in forall).

I do have more forall than do concurrent in my benchmarks, in part
because it's possible to write more efficient (but less readable) source
using merge for the cases in which forall is less suitable for performance.

There was a big thread on this subject recently on this forum; some of
us might be reluctant to rehash the same points. It was pointed out
that declaring forall obsolescent would have relatively little practical
consequence, beyond acknowledging that there may be more alternate
syntax forms than is desirable.


--
Tim Prince

[glen herrmannsfeldt]

Ron Shepard <ron-s...@nospam.comcast.net> wrote:
> In article <lmkrsl$ki9$1...@dont-email.me>,
> Izaak B Beekman <zbee...@gmail.com> wrote:

>> I feel strongly about keeping `where` but, as far as I can tell, `do
>> concurrent` has all of the syntactic conveniences as `forall` with
>> semantics that are much easier for compilers to optimize.

(snip)

> This comment makes the mistake of conflating a vector construct
> (FORALL) with a looping construct (DO CONCURRENT).

> If FORALL is made obsolescent, then how does one write a vector
> expression in terms of its subscripts where the expression needs to
> be completely evaluated before assignment?

Assign to a temporary variable (array) then to the final array.

One problem with FORALL is that the compiler might have to use
a temporary array. The compiler may or may not know when it is
needed, even though you do.

The whole idea behind FORALL was to speed up the case for vector
processors (well, that is what I believe) but the uncertainty in
the need for temporaries means it is likely slower.

Often, you might only need to allocate such temporary once, where
the compiler would have to allocate/deallocate each time through
a loop. And you can check for the case where the allocation failed,
where the compiler allocated temporary can't be checked.

-- glen

[Ian Harvey]

On 2014-06-04 12:43 AM, ftin...@gmail.com wrote:
> On Tuesday, June 3, 2014 10:59:28 AM UTC-3, Dan Nagle wrote:
>> Hi,
>>
>> These's a proposal before WG5 to make forall obsolescent in f15.
>> Should that happen? (I'm asking for opinions -- if thers's
>> a strong enough negative reaction I'll oppose doing so.)

I've put my views/reasoning forward previously here. To summarise - if
1 is diametrically opposed to obsolescence, 3 is don't care and 5 is
can't wait to see it banished - then I'm probably on the scale around 2.

Reasoning beyond that previous post - that alternatives exist to a
particular source construct is not on its own justification for
obsolescing an alternative. That a feature hasn't met the original
motivation for its inclusion doesn't mean that the feature doesn't still
have merit in other ways.

The decision to obsolete that feature should be be made by comparing the
language with the feature and the language with out the feature, and
then consider what the change means for the various stakeholders in the
language. In the rationales for obsolescence that I've read I have not
seen that proper comparison being made.

(Obsolescence is a very strong direction to users of the language that
they should cease using that feature, regardless of the continuation of
compiler support. However the requirement that compiler support be
continued anyway, and the practical reality that in the majority of
cases support for the feature would continue even if it was deleted,
tends to negate any argument around obsolescence providing a benefit to
vendors by making compilers easier to write.)

If FORALL does get made obsolescent, can we have a single statement form
of a DO CONCURRENT construct added in?

(Shame about the selection of keywords for DO CONCURRENT - it doesn't
really have much to do with traditional DO (similar misconception as
thinking that FORALL is a looping construct) and if you are going to use
it as a replacement for FORALL, it is a bit chatty.)

>> This will (largely) be decided during the June 23-27 meeting,
>> in Las Vegas. See http://www.j3-fortran.org for meeting details.
>>
>> --
>> Cheers!
>>
>> Dan Nagle
>
> Hi,
>
> Having worked some years on legacy applications, I've not seen
> forall in any code.

Definitions of "legacy" can obviously differ (perhaps depending on the
legacy of the individual), but given FORALL was only introduced in F95,
I wouldn't expect to see it in legacy code.

[robert....@oracle.com]

On Tuesday, June 3, 2014 9:57:20 AM UTC-7, Ron Shepard wrote:
> In article <lmkrsl$ki9$1...@dont-email.me>,

> Izaak B Beekman wrote:
>
> > I feel strongly about keeping `where` but, as far as I can tell, `do
> > concurrent` has all of the syntactic conveniences as `forall` with
> > semantics that are much easier for compilers to optimize. I have used
> > `forall` in the past, and then been puzzled about performance
> > decreases. It was computationally expressive and convenient for doing
> > things like finite differences, but slow. So long as there is decent
> > compiler support for `do concurrent` by the time the next standard is
> > released, I have no problem with making `forall` obsolescent.
>
> This comment makes the mistake of conflating a vector construct
> (FORALL) with a looping construct (DO CONCURRENT).
>
> If FORALL is made obsolescent, then how does one write a vector
> expression in terms of its subscripts where the expression needs to
> be completely evaluated before assignment?

I supported the proposal to delete FORALL because of all the errors I see programmers make when they use it. The FORALL statement and the WHERE statement are both fairly harmless. I have seen many FORALL statements where the programmer does not use all of the active indices in the variable on the left-hand side of the assignment. The uses of these statements are almost certainly not standard conforming. A simple example is

X = 0.0
FORALL (I=1:N) X = X + A(I)

That statement is not standard conforming, and is unlikely to do what is expected.

The more serious problems are with the FORALL and WHERE constructs. Many programmers seem to think that FORALL and WHERE constructs are looping constructs that execute the statements that forms their bodies repeatedly from top to bottom for the each set of active indices. Instead FORALL and WHERE constructs execute each statement in the body of the construct for all active indices before advancing to the next statement.

Robert Corbett

[Ian Harvey]

Absence of a reference to all indicies on the left hand side should
presumably be easy enough to detect. Are *all* cases of that
non-conforming?

Again, considering what things look like with the alternative (rather
than "this feature has flaws"), the naive transcription to DO CONCURRENT
is equivalently not standard conforming. Like forall, the
non-conformance is not (and in the case of DO CONCURRENT, cannot ever
be) called out by constraint.

DO CONCURRENT (I=1:N) ; X = X + A(I) ; END DO

There's a danger that focussing on isolated simple examples, as I'm
about to do, detracts from a more reasoned overall view, but still - why
is DO CONCURRENT "better" here? If I can botch one form of construct
up, I can botch another that looks very similar!

This is similarly [silly and] nonconforming (though perhaps here
consider X to be an array, and the programmer forgot to subscript it):

FORALL (I=1:N) X = A(I)

This naive transcription conforms... but is still completely useless and
likely to result in non-conforming program in subsequent statements:

DO CONCURRENT (I=1:N) ; X = A(I) ; END DO

Perhaps out of ignorance, I assume the semantics of DO CONCURRENT mean
that a performant compiler has to understand what's going on inside a
simple construct body (vs a construct body where the programmer is being
a little malicious with their complexity) to the extent that it can
identify the "many to one" dependence".

If you can do that analysis for DO CONCURRENT, then you can do it for
FORALL and issue an error diagnostic.

Presumably in the DO CONCURRENT case a compiler that realises it has a
many to one dependence would in this case also realise that it has an
assignment that has no useful effect and could issue a warning
diagnostic. But is the programmer better off?

> The more serious problems are with the FORALL and WHERE constructs.
> Many programmers seem to think that FORALL and WHERE constructs are
> looping constructs that execute the statements that forms their
> bodies repeatedly from top to bottom for the each set of active
> indices. Instead FORALL and WHERE constructs execute each statement
> in the body of the construct for all active indices before advancing
> to the next statement.

A fair enough observation. In that case, why not ditch the
construct forms and keep the single statement forms?

Misconceptions about what you can and can't do inside DO CONCURRENT will
emerge with time too, though - though perhaps debatable whether to the
same extent.

> Robert Corbett

[Richard Maine]

<robert....@oracle.com> wrote:

> I supported the proposal to delete FORALL because of all the errors I see
> programmers make when they use it.

I'd support the obsolescence for basically that reason. Yes, I realize
the features will presumably remain in compilers. But the labelling of
them as obsolescent provides at least a hint to programmers that it is
wise to avoid using them. If programmers avoid using them, then that
will mean that they will avoid

1. Using them in ways that are invalid

and

2. Using them in ways that are valid, but horribly inefficient.

Both of those problems have been observed fairly regularly in the wild.

Obsolescence of forall isn't high on my list of priorities, but yes, I'd
support it.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[robert....@oracle.com]

On Tuesday, June 3, 2014 8:01:18 PM UTC-7, Ian Harvey wrote:
> On 2014-06-04 11:11 AM, robert....@oracle.com wrote:
>
> > I supported the proposal to delete FORALL because of all the errors I
> > see programmers make when they use it. The FORALL statement and the
> > WHERE statement are both fairly harmless. I have seen many FORALL
> > statements where the programmer does not use all of the active
> > indices in the variable on the left-hand side of the assignment. The
> > uses of these statements are almost certainly not standard
> > conforming. A simple example is
> >
> > X = 0.0 ; FORALL (I=1:N) X = X + A(I)
> >
>
> > That statement is not standard conforming, and is unlikely to do what
> > is expected.
>
> Absence of a reference to all indicies on the left hand side should
> presumably be easy enough to detect. Are *all* cases of that
> non-conforming?

No. If N is one or less, it is standard conforming. The only cases I have seen where such a construct was used in a standard-conforming way were in test suites, but standard-conforming processors have to handle them. They are a pain to implement, and their implementation serves no purpose.

> Again, considering what things look like with the alternative (rather
> than "this feature has flaws"), the naive transcription to DO CONCURRENT
> is equivalently not standard conforming. Like forall, the
> non-conformance is not (and in the case of DO CONCURRENT, cannot ever
> be) called out by constraint.

The simple cases, such as in the sample code, could be covered by a contraint. The standard include the constraint that a variable must appear in a context in which it could be defined before it is referenced. I agree that the hard cases cannot always be detected, and therefore

>
>
> DO CONCURRENT (I=1:N) ; X = X + A(I) ; END DO
>
>
>
> There's a danger that focussing on isolated simple examples, as I'm
> about to do, detracts from a more reasoned overall view, but still - why
> is DO CONCURRENT "better" here? If I can botch one form of construct
> up, I can botch another that looks very similar!

One advantage and/or disadvantage of the DO CONCURRENT example is that it will often be implemented in a way that it does what the user expects.

>
> This is similarly [silly and] nonconforming (though perhaps here
> consider X to be an array, and the programmer forgot to subscript it):
>
> FORALL (I=1:N) X = A(I)
>
> This naive transcription conforms... but is still completely useless and
> likely to result in non-conforming program in subsequent statements:
>
> DO CONCURRENT (I=1:N) ; X = A(I) ; END DO
>
> Perhaps out of ignorance, I assume the semantics of DO CONCURRENT mean
> that a performant compiler has to understand what's going on inside a
> simple construct body (vs a construct body where the programmer is being
> a little malicious with their complexity) to the extent that it can
> identify the "many to one" dependence".
>
> If you can do that analysis for DO CONCURRENT, then you can do it for
> FORALL and issue an error diagnostic.

After receiving enough bug reports against our implementation, we added such an error diagnostic.

> Presumably in the DO CONCURRENT case a compiler that realises it has a
> many to one dependence would in this case also realise that it has an
> assignment that has no useful effect and could issue a warning
> diagnostic. But is the programmer better off?
>
> > The more serious problems are with the FORALL and WHERE constructs.
> > Many programmers seem to think that FORALL and WHERE constructs are
> > looping constructs that execute the statements that forms their
> > bodies repeatedly from top to bottom for the each set of active
> > indices. Instead FORALL and WHERE constructs execute each statement
> > in the body of the construct for all active indices before advancing
> > to the next statement.
>
> A fair enough observation. In that case, why not ditch the
> construct forms and keep the single statement forms?

I did propose dumping just the construct forms. No other members of the committee like the idea. One killer argument against was that the WHERE statement has nothing equivalent to ELSEWHERE.

> Misconceptions about what you can and can't do inside DO CONCURRENT will
> emerge with time too, though - though perhaps debatable whether to the
> same extent.

Disagreements about the semantics of DO CONCURRENT have existed since before the Fortran 2008 standard was approved. There have already been several interpretations issued against DO CONCURRENT.

Bob Corbett

[glen herrmannsfeldt]

Ian Harvey <ian_h...@bigpond.com> wrote:

(snip, someone wrote)

>> indices in the variable on the left-hand side of the assignment. The
>> uses of these statements are almost certainly not standard
>> conforming. A simple example is

>> X = 0.0 FORALL (I=1:N) X = X + A(I)

>> That statement is not standard conforming, and is unlikely to do what
>> is expected.

> Absence of a reference to all indicies on the left hand side should
> presumably be easy enough to detect. Are *all* cases of that
> non-conforming?

I think with a WHERE it could be valid. Or if N is 1.

Seems to me that there are many cases where the compiler couldn't
detect it, and some might even be useful.

> Again, considering what things look like with the alternative (rather
> than "this feature has flaws"), the naive transcription to DO CONCURRENT
> is equivalently not standard conforming. Like forall, the
> non-conformance is not (and in the case of DO CONCURRENT, cannot ever
> be) called out by constraint.

> DO CONCURRENT (I=1:N) ; X = X + A(I) ; END DO

In the case of FORALL, if the compiler can't be sure that there
is no overlap between source and destination, a temporary is needed.
There could be many cases where you know that there is no overlap,
but the compiler doesn't.

For DO CONCURRENT, it is your responsibility to get it right.

> There's a danger that focussing on isolated simple examples, as I'm
> about to do, detracts from a more reasoned overall view, but still - why
> is DO CONCURRENT "better" here? If I can botch one form of construct
> up, I can botch another that looks very similar!

> This is similarly [silly and] nonconforming (though perhaps here
> consider X to be an array, and the programmer forgot to subscript it):

> FORALL (I=1:N) X = A(I)

Well, one could forget to subscript arrays in a lot of places,
such as READ or WRITE statements, and get surprising results.

> This naive transcription conforms... but is still completely useless and
> likely to result in non-conforming program in subsequent statements:

> DO CONCURRENT (I=1:N) ; X = A(I) ; END DO

> Perhaps out of ignorance, I assume the semantics of DO CONCURRENT mean
> that a performant compiler has to understand what's going on inside a
> simple construct body (vs a construct body where the programmer is being
> a little malicious with their complexity) to the extent that it can
> identify the "many to one" dependence".

Well, it seems to me that DO CONCURRENT has some similarity to
what you can do with MPI or OpenMP. In both cases, the result is
that X is undefined.

> If you can do that analysis for DO CONCURRENT, then you can do it for
> FORALL and issue an error diagnostic.

The interesting cases are the ones the compiler can't figure out.

Consider (from the Fortran 2008 standard in 7.2.4.4)

FORALL (I=1:10)
A(INDEX(I))=B(I)
END FORALL

is valid if there are no repeated values in INDEX(1:10).

Note that this can be conveniently done using vector registers
in a processor with scatter/gather capability.

Now, consider:

FORALL (I=1:10)
B(INDEX(I))=B(I)
END FORALL

and again, the values in INDEX(1:10) are unique. Even more,
consider that none of the values of INDEX(1:10) are between 1 and 10.

> Presumably in the DO CONCURRENT case a compiler that realises it has a
> many to one dependence would in this case also realise that it has an
> assignment that has no useful effect and could issue a warning
> diagnostic. But is the programmer better off?

In the easy cases, the compiler should probably give a diagnostic,
but then again, the easy cases us using a variable before assigning
it a value should also be diagnosed, and many compilers don't.
(They are getting better, though.)

>> The more serious problems are with the FORALL and WHERE constructs.
>> Many programmers seem to think that FORALL and WHERE constructs are
>> looping constructs that execute the statements that forms their
>> bodies repeatedly from top to bottom for the each set of active
>> indices. Instead FORALL and WHERE constructs execute each statement
>> in the body of the construct for all active indices before advancing
>> to the next statement.

> A fair enough observation. In that case, why not ditch the
> construct forms and keep the single statement forms?

> Misconceptions about what you can and can't do inside DO CONCURRENT will
> emerge with time too, though - though perhaps debatable whether to the
> same extent.

-- glen

[glen herrmannsfeldt]

robert....@oracle.com wrote:

(snip)

>> > X = 0.0 ; FORALL (I=1:N) X = X + A(I)

(snip, someone wrote)

>> Absence of a reference to all indicies on the left hand side should
>> presumably be easy enough to detect. Are *all* cases of that
>> non-conforming?

> No. If N is one or less, it is standard conforming.
> The only cases I have seen where such a construct was used in
> a standard-conforming way were in test suites, but
> standard-conforming processors have to handle them.
> They are a pain to implement, and their implementation
> serves no purpose.

Seems to me that there are also some with WHERE, or even:

FORALL(I=1:N, I.EQ.M) X=X+A(I)

which, as usual, can be done in a simpler way.

-- glen

[Wolfgang Kilian]

There is an important distinction between FORALL and WHERE. The WHERE
construct enables index-free notation in cases where the available
alternatives require indices. This should definitely be kept.

FORALL: Looking at the F2008 standard, the DO CONCURRENT syntax is
defined via the forall-header ... the text that is now defining FORALL
would be moved to the description of DO, without much simplification.
A more useful change would be to have ordinary DO support the same
header as (FORALL and) DO CONCURRENT. As a programmer, just
delete/insert a keyword whenever the requirements for concurrent
execution are (no longer) met, after a code change ...

So, I'm not opposed to obsolescence here, but I'd prefer this to be done
in the context of an effort to make the whole picture more consistent ..
which probably means: postpone to the next revision.

-- Wolfgang

--
E-mail: firstnameini...@domain.de
Domain: yahoo

[Wolfgang Kilian]

Some compilers already do wonders in detecting runtime errors
(non-standard/undefined behavior caused by actual program flow). I can
imagine a compiler, with some debugging flag set, keeping track of
potential conflicts and detect this at runtime, just like out-of-bound
access. Such tracking might be easier for FORALL than for DO CONCURRENT.

>>> The more serious problems are with the FORALL and WHERE constructs.
>>> Many programmers seem to think that FORALL and WHERE constructs are
>>> looping constructs that execute the statements that forms their
>>> bodies repeatedly from top to bottom for the each set of active
>>> indices. Instead FORALL and WHERE constructs execute each statement
>>> in the body of the construct for all active indices before advancing
>>> to the next statement.
>
>> A fair enough observation. In that case, why not ditch the
>> construct forms and keep the single statement forms?

Because ELSEWHERE is also necessary. In the case of FORALL, the block
form is less important.

>> Misconceptions about what you can and can't do inside DO CONCURRENT will
>> emerge with time too, though - though perhaps debatable whether to the
>> same extent.
>
> -- glen
>

[robert....@oracle.com]

On Wednesday, June 4, 2014 12:21:32 AM UTC-7, Wolfgang Kilian wrote:
>
> FORALL: Looking at the F2008 standard, the DO CONCURRENT syntax is
> defined via the forall-header ... the text that is now defining FORALL
> would be moved to the description of DO, without much simplification.

The edits for that change were approved at the last meeting. They were lengthy.

> A more useful change would be to have ordinary DO support the same
> header as (FORALL and) DO CONCURRENT.

I do not see what the semantics of such a looping construct would be.

> As a programmer, just
> delete/insert a keyword whenever the requirements for concurrent
> execution are (no longer) met, after a code change ...
>
> So, I'm not opposed to obsolescence here, but I'd prefer this to be done
> in the context of an effort to make the whole picture more consistent ..
> which probably means: postpone to the next revision.

There is still time to make big changes to the standard. Wart removal was one of the stated goals for the next standard.

Bob Corbett

[Wolfgang Kilian]

On 06/04/2014 10:59 AM, robert....@oracle.com wrote:
> On Wednesday, June 4, 2014 12:21:32 AM UTC-7, Wolfgang Kilian wrote:
>>
>> FORALL: Looking at the F2008 standard, the DO CONCURRENT syntax is
>> defined via the forall-header ... the text that is now defining FORALL
>> would be moved to the description of DO, without much simplification.
>
> The edits for that change were approved at the last meeting. They were lengthy.
>
>> A more useful change would be to have ordinary DO support the same
>> header as (FORALL and) DO CONCURRENT.
>
> I do not see what the semantics of such a looping construct would be.

I may be ignorant, but I'd expect that it is the same as for DO
CONCURRENT, except that the body of the loop is iterated in a
well-defined order, skipping iterations where the mask expression is
false. Most, or all of the extra constraints would not apply. Some
analogy with ELEMENTAL vs. IMPURE ELEMENTAL procedures.

I don't say that this adds functionality. It is just a syntax that is
more consistent with various ways of array handling and, in particular,
DO CONCURRENT. In some cases (trivially nested loops, simple mask
expression) it is also more compact. I think that this has been
discussed before in this newsgroup.

>> As a programmer, just
>> delete/insert a keyword whenever the requirements for concurrent
>> execution are (no longer) met, after a code change ...
>>
>> So, I'm not opposed to obsolescence here, but I'd prefer this to be done
>> in the context of an effort to make the whole picture more consistent ..
>> which probably means: postpone to the next revision.
>
> There is still time to make big changes to the standard. Wart removal was one of the stated goals for the next standard.

Just curious - is there anything on the agenda that does not concern
coarrays or C interop?

> Bob Corbett

[FortranFan]

Dan,

Thank you very much for soliciting feedback on this proposal - appreciate your thoughtfulness greatly.

I do like the syntactic expressiveness of FORALL and I do use it for simple stuff even where parallel programming is not of any interest. For example,

FORALL (I = 1:SomeInputLength)
SomeType(I)%SomeData => SomeInputData(I)
END FORALL

My opinion is my code reads much better with FORALL in the places where I use it than other ways of achieving the same result (such as DO CONCURRENT).

Hence I request a vote AGAINST making it obsolescent.

Best Regards,

[Harald Anlauf]

We have tons of similar "legacy" (pre-F201x) code with valid uses of FORALL.
I don't really buy the arguments brought forward about non-conforming code
in the wild to justify killing this feature.

I do understand that it may be a difficult job for a Fortran compiler and
runtime to diagnose invalid code. Some do a better job here, others not.
Judging from my experience with vectorizing compilers, this is not a trivial
task. But FORALL is not the culprit.

Since we'd like to keep our "investments", I'd also vote against obsolescence
of FORALL.

[ftin...@gmail.com]

On Tuesday, June 3, 2014 9:56:39 PM UTC-3, Ian Harvey wrote:
> On 2014-06-04 12:43 AM, ftin...@gmail.com wrote:

[snip]

>
> > Hi,
> >
> > Having worked some years on legacy applications, I've not seen
> > forall in any code.
>
> Definitions of "legacy" can obviously differ (perhaps depending on the
> legacy of the individual),

In my case, I've been working on several millions of lines of code (4.2 M LOC from weather/climade models in particular).

> but given FORALL was only introduced in F95,
> I wouldn't expect to see it in legacy code.

Actually, legacy code is not necessarily tied to pre- or post- some year or standard date, but it is not the point here, or at least it is not something I would discuss now/in this thread (at least no more than what I've just written).

Fernando.

[robert....@oracle.com]

On Wednesday, June 4, 2014 4:44:01 AM UTC-7, Wolfgang Kilian wrote:
>
> Just curious - is there anything on the agenda that does not concern
> coarrays or C interop?

For the list of work items for the next standard that were approved last year, go to the SC22/WG5 website and read paper N1982. Among other items, arithmetic IF and some forms of DO-loops are being deleted, and common blocks, EQUIVALENCE, and specific intrinsic functions are being declared to be obsolescent.

Bob Corbett

[Wolfgang Kilian]

Thanks. No big changes to the F2008 standard (I don't object, I don't
even have access to a F2003 compiler).

[Dan Nagle]

Hi,

On 2014-06-05 08:44:17 +0000, Wolfgang Kilian said:

> On 06/05/2014 01:27 AM, robert....@oracle.com wrote:
>> On Wednesday, June 4, 2014 4:44:01 AM UTC-7, Wolfgang Kilian wrote:
>>>
>>> Just curious - is there anything on the agenda that does not concern
>>> coarrays or C interop?
>>
>> For the list of work items for the next standard that were approved
>> last year, go to the SC22/WG5 website and read paper N1982. Among
>> other items, arithmetic IF and some forms of DO-loops are being
>> deleted, and common blocks, EQUIVALENCE, and specific intrinsic
>> functions are being declared to be obsolescent.
>
> Thanks. No big changes to the F2008 standard (I don't object, I don't
> even have access to a F2003 compiler).

Also www.j3-fortran.org and click on "work plan" on the home page.
This is a list of paper numbers describing the individual items.
Click on "Complete J3 Document Archive" near the bottom, find the year,
then download the particular paper. (J3 papers are yy-nnn where
yy is the last two digits of the year and nnn is the paper number-
always read the highest r number: yy-nnnrm, read the highest m)

The strategy is to produce a very small revision to give compilers
a chance to implement all of the latest standard. This is generally
agreed, but a few are unhappy that, effectively, there's no new features.
(f15 will be the TS on Interop, the TS on coarrays, a lot of Interps,
some wordsmithing, and a few small fixes.)

ISTR enough negative comments about removing forall that I thought I'd ask.

A strong case could probably persuade the committee either way.

--
Cheers!

Dan Nagle

[alexei....@gmail.com]

> These's a proposal before WG5 to make forall obsolescent in f15.

When I didnt want to decide on the loop order I used to
turn to forall:

forall(ma=1:2*LA+1, mb=1:2*LB+1, lla=0:LA, llb=0:LB)
X2P(ma,mb,1+lla,1+llb,1+llp) = X2P(ma,mb,1+lla,1+llb,1+llp) &
+ PRA(C00,ma,1+lla) * PRB(C00,mb,1+llb)
end forall

There are a few:

$ grep -iw forall */*.f90 | wc
111 650 7381

Alexei

[Wolfgang Kilian]

On 06/05/2014 04:04 PM, Dan Nagle wrote:
> Hi,
>
> On 2014-06-05 08:44:17 +0000, Wolfgang Kilian said:
>
>> On 06/05/2014 01:27 AM, robert....@oracle.com wrote:
>>> On Wednesday, June 4, 2014 4:44:01 AM UTC-7, Wolfgang Kilian wrote:
>>>>
>>>> Just curious - is there anything on the agenda that does not concern
>>>> coarrays or C interop?
>>>
>>> For the list of work items for the next standard that were approved
>>> last year, go to the SC22/WG5 website and read paper N1982. Among
>>> other items, arithmetic IF and some forms of DO-loops are being
>>> deleted, and common blocks, EQUIVALENCE, and specific intrinsic
>>> functions are being declared to be obsolescent.
>>
>> Thanks. No big changes to the F2008 standard (I don't object, I don't
>> even have access to a F2003 compiler).
>
> Also www.j3-fortran.org and click on "work plan" on the home page.
> This is a list of paper numbers describing the individual items.
> Click on "Complete J3 Document Archive" near the bottom, find the year,
> then download the particular paper. (J3 papers are yy-nnn where
> yy is the last two digits of the year and nnn is the paper number-
> always read the highest r number: yy-nnnrm, read the highest m)

Thanks, again.

> The strategy is to produce a very small revision to give compilers
> a chance to implement all of the latest standard. This is generally
> agreed, but a few are unhappy that, effectively, there's no new features.
> (f15 will be the TS on Interop, the TS on coarrays, a lot of Interps,
> some wordsmithing, and a few small fixes.)

Certainly reasonable. I hope that after that, the committee will be
open to address some bigger issues. Writing new code, I'm missing most
the generic-programming capabilities that almost every modern language
has, and that in a compiled language wouldn't degrade efficiency at all.
Not an easy task to define properly, I admit.

> ISTR enough negative comments about removing forall that I thought I'd ask.
>
> A strong case could probably persuade the committee either way.

Since current codes apparently do make use of FORALL, if only as a
syntactical abbreviation, removing it might be not so welcome anymore ...

[glen herrmannsfeldt]

Wolfgang Kilian <kil...@invalid.com> wrote:

(snip)

> Since current codes apparently do make use of FORALL, if only as a
> syntactical abbreviation, removing it might be not so welcome
> anymore ...

As well as I know it, obsolescent only suggests that something might
be remvoed in the future. It also discourages its use in new code.

As far as I know, there is no way to specify the latter without
the former.

There are many obsolescent, or even deleted, features that could
easily be automatically replaced by other constructs.

-- glen

[Dan Nagle]

Hi,

On 2014-06-06 08:41:02 +0000, Wolfgang Kilian said:

> I hope that after that, the committee will be open to address some
> bigger issues. Writing new code, I'm missing most the
> generic-programming capabilities that almost every modern language has,
> and that in a compiled language wouldn't degrade efficiency at all.
> Not an easy task to define properly, I admit.

A concern I've had recently about generic programming is the loss if
type safety,
if not done very carefully. A proposal during the draft of f08 would have
lead to code where any compile-time error message would have been very
difficult
to trace back to the line of code actually written by the programmer.
I objected
strongly on those grounds as did some others. The feature was dropped
due to a lack of consensus.

I know is a popular request, but there's resistance from the vendors, and
getting it right is difficult.

Right now, it's difficult to say just when new features will be considered.
My best guess at this time is something like 2016 or 2017 or so. It may
depend on how fast f03 and f08 compilers actually appear. f15 compilers
should appear very soon after f08 compilers.

--
Cheers!

Dan Nagle

[Gordon Sande]

Hopefully one of the minor fixes will be to allow some form of alphanumerical
identifiers for statement labels. Construct names seems to be awfully close.
Under the time honored duck test of walking, quacking and looking a
duck they are
hard to tell apart.

The folks who want this sort of thing are those who collect a bunch of error
exits at the bottom of their code at statement labels like 8000, 9000 etc.
It would be so much better if those could be end-of-file: etc. I would even put
up with not not having them in columns 1 through 5 in fixed format source and
always having to include a colon to mark them as special.

[Wolfgang Kilian]

On 06/06/2014 04:14 PM, Dan Nagle wrote:
> Hi,
>
> On 2014-06-06 08:41:02 +0000, Wolfgang Kilian said:
>
>> I hope that after that, the committee will be open to address some
>> bigger issues. Writing new code, I'm missing most the
>> generic-programming capabilities that almost every modern language
>> has, and that in a compiled language wouldn't degrade efficiency at
>> all. Not an easy task to define properly, I admit.
>
> A concern I've had recently about generic programming is the loss if
> type safety,
> if not done very carefully. A proposal during the draft of f08 would have
> lead to code where any compile-time error message would have been very
> difficult
> to trace back to the line of code actually written by the programmer. I
> objected
> strongly on those grounds as did some others. The feature was dropped
> due to a lack of consensus.

No objection. There are now many different incarnations of generic
programming in modern languages, which could be studied carefully in
that respect. Some of them in strongly typed languages (some more
'strongly' typed than Fortran, actually).

>
> I know is a popular request, but there's resistance from the vendors, and
> getting it right is difficult.

Yes, this is a difficult area and shouldn't be rushed. But I
(personally) think it is the most useful 'major' feature that is missing
in Fortran.

> Right now, it's difficult to say just when new features will be considered.
> My best guess at this time is something like 2016 or 2017 or so. It may
> depend on how fast f03 and f08 compilers actually appear. f15 compilers
> should appear very soon after f08 compilers.

Hopefully. Thanks for the detailed explanations.