Interesting paper of generics in Fortran on J3 site

[Richard Weed]

I went to the J3 web site (www.j3-fortran.org) to start going back over all the documents from the past few revision iterations to see if any of the ideas for modifications to Fortran I have were previously considered. I ran across the following paper "Reflecting on Generics for Fortran" by Haveraaen, Jarvi, and Rouson. (see paper 19-188.pdf at https://j3-fortran.org/doc/year/19). I found it to be an excellent analysis of the pros and cons of the different methods for implementing generics in programming languages. It highlites some of the deficiencies in various methods in particular C++ templates. This is the first time I've seen this spelled out in detail (and makes me very leary of adding C++ style templates to Fortran). Hopefully they will consider submitting it or an expanded paper to some journal or Fortran Forum (if it is still active) so it will get a wider audience. Its worth a read for anyone interested in generics in Fortran

[Arjen Markus]

On Saturday, August 3, 2019 at 3:17:58 PM UTC+2, Richard Weed wrote:
> I went to the J3 web site (www.j3-fortran.org) to start going back over all the documents from the past few revision iterations to see if any of the ideas for modifications to Fortran I have were previously considered. I ran across the following paper "Reflecting on Generics for Fortran" by Haveraaen, Jarvi, and Rouson. (see paper 19-188.pdf at https://j3-fortran.org/doc/year/19). I found it to be an excellent analysis of the pros and cons of the different methods for implementing generics in programming languages. It highlites some of the deficiencies in various methods in particular C++ templates. This is the first time I've seen this spelled out in detail (and makes me very leary of adding C++ style templates to Fortran). Hopefully they will consider submitting it or an expanded paper to some journal or Fortran Forum (if it is still active) so it will get a wider audience. Its worth a read for anyone interested in generics in Fortran

Thanks for pointing this out - it so happens that I am working on a note about generic programming in Fortran myself.

As a side note: Two of these authors were involved in a paper on design patterns, https://www.researchgate.net/publication/262241507_High-Performance_Design_Patterns_for_Modern_Fortran, that might be of some interest in the general topic of generic programming (that is, not just cater for data types, but for the mathematics behind it all as well, to put it in somewhat grandiose terms)

Regards,

Arjen

[Steve Lionel]

On 8/3/2019 10:17 PM, Richard Weed wrote:
> I went to the J3 web site (www.j3-fortran.org) to start going back over all the documents from the past few revision iterations to see if any of the ideas for modifications to Fortran I have were previously considered. I ran across the following paper "Reflecting on Generics for Fortran" by Haveraaen, Jarvi, and Rouson.

Haveraaen and Rouson are here at the WG5/J3 meeting this week, and we
intend to discuss the paper.

--
Steve Lionel
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: http://intel.com/software/DrFortran

[Arjen Markus]

I read this paper with interest. What is even more interesting is that a lot of what they present can already be achieved with Fortran as it is. (Yesterday evening I completed encoding my experiment with generic features. Not yet my note, though, describing what I did :). So That Should be Completed Real Soon)

Regards,

Arjen

[Steve Lionel]

On 8/13/2019 2:58 AM, Arjen Markus wrote:
> On Monday, August 5, 2019 at 10:24:26 AM UTC+2, Steve Lionel wrote:
>> On 8/3/2019 10:17 PM, Richard Weed wrote:
>>> I went to the J3 web site (www.j3-fortran.org) to start going back over all the documents from the past few revision iterations to see if any of the ideas for modifications to Fortran I have were previously considered. I ran across the following paper "Reflecting on Generics for Fortran" by Haveraaen, Jarvi, and Rouson.
>>
>> Haveraaen and Rouson are here at the WG5/J3 meeting this week, and we
>> intend to discuss the paper.
>>
>

> I read this paper with interest. What is even more interesting is that a lot of what they present can already be achieved with Fortran as it is. (Yesterday evening I completed encoding my experiment with generic features. Not yet my note, though, describing what I did :). So That Should be Completed Real Soon)

I agree that a lot can be done with Fortran today. I often find that
Fortran programmers ask for things already in the language (and widely
supported.)

At last week's WG5 meeting, the general agreement was that improving
generics support, possibly with some sort of template system, was
important. But it was also felt that it was too big a feature to try to
get done for Fortran 202X, especially when there was not yet consensus
on the approach to take. There are lessons to be learned from what other
languages have tried.

Magne Haveraaen's contribution to the discussion was valuable and we
invited him to continue participation.

WG5 resolved that work would begin now on developing such a feature for
inclusion in the following revision, which we're calling Fortran 202Y.
(And note that the third digit is a 2, not a 3.)

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor

Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: http://intel.com/software/DrFortran

WG5: https://wg5-fortran.org

[FortranFan]

On Wednesday, August 14, 2019 at 9:57:39 AM UTC-4, Steve Lionel wrote:

> ..

> I agree that a lot can be done with Fortran today. I often find that
> Fortran programmers ask for things already in the language (and widely
> supported.)

> ..

Take the WG5 survey results: document N2147 at https://isotc.iso.org/livelink/livelink?func=ll&objId=19530634&objAction=Open&viewType=1

Can you provide a few examples where "Fortran programmers ask for things already in the language"?

Sure there are some Fortran users for whom the language is effectively synonymous with their dialect of choice, one that is some non-standard extension of FORTRAN 77, and whose suggestions for revisions of the standard can come across as "mission accomplished" to the committee!

However, the feedback in the WG5 survey which pertain to *requests* appear to specifically address limitations in the current version of the standard, Fortran 2018.

[steve kargl]

FortranFan wrote:

> On Wednesday, August 14, 2019 at 9:57:39 AM UTC-4, Steve Lionel wrote:
>
>> ..
>> I agree that a lot can be done with Fortran today. I often find that
>> Fortran programmers ask for things already in the language (and widely
>> supported.)
>> ..
>
> Take the WG5 survey results: document N2147 at https://isotc.iso.org/livelink/livelink?func=ll&objId=19530634&objAction=Open&viewType=1
>
> Can you provide a few examples where "Fortran programmers ask for things already in the language"?
>

Let's turn this around. Why don't you take the survey and show how none
of the items in the survey can be implemented in Fortran?

--
steve

[FortranFan]

On Wednesday, August 14, 2019 at 11:08:23 PM UTC-4, steve kargl wrote:

> ..

> Let's turn this around. Why don't you take the survey and show how none
> of the items in the survey can be implemented in Fortran?

> ..

Readers will note I've made many attempts to show this. Take generic programming for instance. As mentioned in the paper referenced in the original post, a rather common need in generic programming is a generic swap, a use case of which can be immediately noticed in illustrations of sorting algorithms in textbooks, say Quick Sort by Cormen et al, to sort lists of any type. See my comment in this thread more than a year ago:
https://groups.google.com/d/msg/comp.lang.fortran/96tohCrlwV0/pHjDMXUVAQAJ

So what @Arjen Markus appears to attempt is nothing new as a general concept, meaning whether "one can do a lot with Fortran today" - yes, surely one can do quite a few things using Fortran; arguably develop an operating system also with Fortran. The issue is that at practically every instance in time since 1969, coders have been able to do a lot *more* with other programming languages, have selected them over Fortran for many, many applications, and they continue to do so.

With the current language standard for Fortran, it's prohibitively "expensive", particularly in a commercial/industrial context, to develop reusable code that can work for a variety of applications. A "generic" swap procedure itself, a rather simple and essentially a canonical need in generic programming, when attempted in Fortran will be nowhere competitive in terms of verbosity and its comprehensiveness and maintenance aspects relative to other coding approaches available to young, bright engineers in this day and age:

With modern C++, a young coder will simply do:
std::swap(x, y);

where x, y can be any type. And the coder will be aware of another standard utility with the *move* operation that can work with any type. Developing reusable collection classes then becomes a much more efficient pursuit compared to Fortran notwithstanding any issue with long, cryptic messages, etc. with any errors during template instantiation.

The point I've been trying to make for quite some time has been captured in this paragraph by Haveraaen et al., "A more important problem, however, is the source code bloat that software developers experience when having to implement the same source code for different combinations of types and operations. Such duplication leads to huge maintenance problems, far more significant than a possible code bloat effect for compiled code."

So what coders have been feeding back to WG5 such as with the survey last year is that the Fortran remains impractical for some of the modern coding needs such as reusable collection classes, in fact for all of the use cases listed in section 3 of the Haveraaen et al. paper.

[ga...@u.washington.edu]

On Wednesday, August 14, 2019 at 9:11:21 PM UTC-7, FortranFan wrote:

(snip)

> Readers will note I've made many attempts to show this.
> Take generic programming for instance. As mentioned in the paper
> referenced in the original post, a rather common need in generic
> programming is a generic swap, a use case of which can be
> immediately noticed in illustrations of sorting algorithms in
> textbooks, say Quick Sort by Cormen et al, to sort lists of any type.
> See my comment in this thread more than a year ago:
> https://groups.google.com/d/msg/comp.lang.fortran/96tohCrlwV0/pHjDMXUVAQAJ

C has ways to use sizeof and memcpy to swap generic data knowing
only its size. It is a little strange, but does work.

In Java, everything except the primitive types (byte, short, char,
int, long, float, and double) is done through a reference. That
includes arrays.

(Many users of C's qsort() sort arrays of pointers instead of arrays
of actual data.)

In addition to sort routines for the primitive types, there is one
that will sort arrays of Object. For classes that implement
(Java term) the Comparable interface, one can directly call the
sort routine. Otherwise, one supplies a routine to compare two
Object values as desired.

It is not so hard to call C's qsort(), either with an array of
structures or an array of C_PTR. So, can it be done in Fortran
without using any C-interoperability features?

[Ev. Drikos]

On 15/08/2019 7:11 AM, FortranFan wrote:
> On Wednesday, August 14, 2019 at 11:08:23 PM UTC-4, steve kargl wrote:
>
>> ..
>

> With the current language standard for Fortran, it's prohibitively "expensive", particularly in a commercial/industrial context, to develop reusable code that can work for a variety of applications. A "generic" swap procedure itself, a rather simple and essentially a canonical need in generic programming, when attempted in Fortran will be nowhere competitive in terms of verbosity and its comprehensiveness and maintenance aspects relative to other coding approaches available to young, bright engineers in this day and age:
>
> With modern C++, a young coder will simply do:

> ...

@everyone

BTW, simplicity & clarity are of paramount importance because end users
will unavoidably compare the upcoming Fortran solution to the solution
already supported in other languages, ie C++.

Below there is a small example that divides numbers by two. The function
header is just **one** line.


-----------------------------------------------------------------------

#include <stdio.h>

// A Function Template that divides a number by two
template <typename T>T half(T v){
return v/2;
}

//Specialization for character types
template <>char half(char v){
if ( v>='A' && v <= 'Z' )
return v+32 ;
else
return v;
}

int main(int argc, const char * argv[]) {
int i=10;
long l=10000;
char c='C';

printf("value(i)= %5d, value(l)=%5ld, value( c ) =%c \n", i,l,c );
printf(" half(i)= %5d, half(l)=%5ld, half( c :-) =%c \n",
half(i),half(l),half(c));

return 0;
}

[Ev. Drikos]

On 15/08/2019 10:22 AM, ga...@u.washington.edu wrote:
> On Wednesday, August 14, 2019 at 9:11:21 PM UTC-7, FortranFan wrote:
>
> (snip)
>
>

> In Java, everything except the primitive types (byte, short, char,
> int, long, float, and double) is done through a reference. That
> includes arrays.
>

At least up to version 1.6, Java supported templates syntax mainly
for static type checking, ie with various containers to help one avoid
dynamic type casting at run-time. That explained, I'd the impression
that templates weren't fully supported.

Does Java supports now generic programming as ie C++ does?

[Steve Lionel]

On 8/14/2019 10:11 PM, FortranFan wrote:
> Can you provide a few examples where "Fortran programmers ask for things already in the language"?

Sure - I got these at a recent Q+A:

"I would like a language feature to get elapsed time." (SYSTEM_CLOCK)
"I would like support for quad precision" (If a platform supports it,
there will be a REAL kind for it.)
"Support for multibyte characters" (Character kinds.)
"Support for NotANumber" (IEEE modules)
"Introduction of parallel constructs outside of OpenMP" (Coarrays and DO
CONCURRENT)

Those are just the most recent examples I can recall.

Please don't misunderstand - WG5 recognizes the language's shortcomings
in regards to generic programming, especially with combinatorial
explosion of interfaces. We are committed to providing this capability
but don't want to do a half-baked job of it. There are various needs
programmers have and some of them conflict. We'll be looking at other
languages to see what worked and what didn't.

[Thomas Koenig]

Steve Lionel <st...@seesignature.invalid> schrieb:

> Please don't misunderstand - WG5 recognizes the language's shortcomings
> in regards to generic programming, especially with combinatorial
> explosion of interfaces. We are committed to providing this capability
> but don't want to do a half-baked job of it. There are various needs
> programmers have and some of them conflict. We'll be looking at other
> languages to see what worked and what didn't.

I would like to commend the committee on this approach.

With generics, there are so many things that can go wrong, and have
gone wrong, in other programming languages, and it makes a _lot_
of sense to try and not to repeat them.

[Rudi Gaelzer]

On Thursday, August 15, 2019 at 2:25:28 PM UTC-3, Thomas Koenig wrote:
> Steve Lionel schrieb:

I, for one, would really appreciate if you or Steve or someone else from the committee could find some time and point out some of the correct/wrong approaches to generics in other languages.

[Steve Lionel]

On 8/16/2019 5:43 PM, Rudi Gaelzer wrote:
> I, for one, would really appreciate if you or Steve or someone else from the committee could find some time and point out some of the correct/wrong approaches to generics in other languages.

It won't be me - this is not my area of expertise. I would hesitate to
label things "correct" or "wrong". As I understand it, some approaches
have limitations that didn't become apparent until some time after they
were implemented. That doesn't make them wrong. (For an example of this
from Fortran, look at FORALL.)

You can probably find lots of papers/articles on the topic if you look.
There are also existing papers on the J3 site (https://j3-fortran.org/)
from recent meetings with various suggested approaches and opinions. I
have no interest in litigating it here.

I expect WG5 to converge on an approach that draws from the best of
other languages, fits well with Fortran, and solves major issues Fortran
programmers encounter today. Will it solve everyone's issues? Unlikely.

I did hear that the Flang/F18 developers are thinking about prototyping
some approaches - I would very much encourage that.

[Thomas Koenig]

Steve Lionel <st...@seesignature.invalid> schrieb:

> You can probably find lots of papers/articles on the topic if you look.
> There are also existing papers on the J3 site (https://j3-fortran.org/)
> from recent meetings with various suggested approaches and opinions.

https://j3-fortran.org/doc/year/19/19-188.pdf does a pretty good
job (IMHO) pointing out what went wrong in other languages, and
what can be made better in Fortran as a result.

[David Duffy]

FortranFan <pare...@gmail.com> wrote:
>
> a language system and an
> implementation framework that gets *GENERICS just about RIGHT* and that
> is Microsoft with their .NET system and C# and Visual Basic languages.

I am pretty ignorant about compiler implementation, but to
make their generics so performant the C# runtime seems to have
particular properties. The most obvious is JIT compilation supporting
new instances of a generic, but I guess garbage collection may be
necessary to assist such an approach. Would that mean that a flavour
of Fortran supporting this might only be one compiler or platform?

> --- Example of RIDICULOUS code duplication with current Fortran ---

But unless one is taking the C# approach, this always happens anyway at
the level of the executable code doesn't it? It is tedious, but there
are several Fortran metaprogramming tools that can automate this, none
of which seems particularly popular.

Just 2c, from an interest in discussion by people with more experience of
these matters.

David Duffy.

[FortranFan]

On Saturday, August 17, 2019 at 9:19:15 AM UTC-4, Thomas Koenig wrote:

> ..https://j3-fortran.org/doc/year/19/19-188.pdf does a pretty good

> job (IMHO) pointing out what went wrong in other languages, and
> what can be made better in Fortran as a result.

To write the paper "does a .. good job pointing out what went wrong in other languages" is NOT right. Readers would do well to refer back to Steve Lionel's comment in the previous post, "I would hesitate to label things "correct" or "wrong". As I understand it, some approaches have limitations that didn't become apparent until some time after they were implemented. That doesn't make them wrong. (For an example of this from Fortran, look at FORALL.) "

On Saturday, August 17, 2019 at 9:08:06 AM UTC-4, Steve Lionel wrote:
> ..

> I expect WG5 to converge on an approach that draws from the best of
> other languages, fits well with Fortran, and solves major issues Fortran
> programmers encounter today. Will it solve everyone's issues? Unlikely.

> ..


The question for WG5 remains WHEN will enhanced generics appear in Fortran, perhaps in 202y? And in which case *reliable* processor (compiler) implementations will become available in 2045, if at all?

Before attempting to answer that question, WG5 should really ask itself 2 fundamental questions:

For whom Fortran? For what?

Readers should take note of 2 points:

1) On one hand the ISO IEC standard is entirely silent on the above 2 questions but unabashedly presents Fortran as some general-purpose language for everyone for everything, including for unicorns for the purpose of making skittles!

2) On the other hand, every decision and direction taken by the committee has to satisfy the interests of certain TENURED institutional reps toward a few long-standing programs toward particular applications in so-called scientific and numerical computing and their suppliers, the compiler vendors, who only see certain limited returns on their efforts with Fortran language and thus are inclined to adopt minimalism and where "performance and backward compatibility", like industrial SAFETY post-Bhopal in chemical industry, are wielded like the double-edged sword: one can "kill" any and all feedback from ordinary practitioners with these 2 undeniable notions OR when a clique forms with a strong interest in something like SPMD with PGAS approach using COARRAYS, one can sell any idea using such considerations even if the work can be of little benefit to so many in the computing world where Fortran is mostly in a few libraries and that "single program" in SP can be anything but a Fortran main program i.e., a 3rd-party simulator, a spreadsheet program, a web browser, some opaque thingy running on the cloud, ...

All the while, the computing world keeps advancing rapidly but where

NO LARGE, NEW programs, worthy of any consideration especially in industry, get developed in Fortran, period.

The above points are especially important in the case of generics: because if Fortran is truly intended to be a general-purpose language for a wide variety of applications as mentioned in point 1, then considerations involving any issues faced by the practitioners of C++ and Java might become meaningful.

However, like with everything else particularly OO, if Fortran is immediately predisposed to including only the MINIMUM facilities in the language for specific needs as envisioned by those reps with their "scientific and numerical computing" applications with considerations of "performance and backward compatibility", then why go around bad-mouthing C++, Java, etc. at all? That is, when the "scientific and numerical computing" developers using these other languages mostly adopt a small set of the Templates/Generics features of these languages where the stated issues such as in paper 19-188 are of little relevance.

Separately, readers here and especially WG5 (should it be serious about generics) will take take note there is a language system and an implementation framework that gets *GENERICS just about RIGHT* and that is Microsoft with their .NET system and C# and Visual Basic languages.

C# and Visual Basic are reasonably close to efficient and practicable examples of languages that draws from the best of other languages such as C++ and Java, adopts aspects that fit well with their existing platforms, and solves major issues faced earlier by their programmers. C# and Visual Basic find ever-increasing applications, especially in industry, in many domains including the "scientific and numerical computing" ones.

So what would it take for WG5 to take a close look at generics in Microsoft C#/Visual Basic.NET? I ask given the tacit and persisting bias I notice against Microsoft's solutions by many, one which can be especially VIRULENT among the academia (it's rather strange the lead author of paper 19-188 makes no reference to either C# or Visual Basic in that paper) but also by certain influencers in connection with Fortran. It appears an uphill battle, nearly an impossible one, to "market" .NET languages successfully as only examples to look at and to give them a basic (pun intended) level of consideration toward feature development in Fortran.

Features delayed are features denied. Excluding generics from Fortran 202x is already doing an indescribable amount of disservice to practitioners of Fortran.

But that WG5 won't agree to provide even an intrinsic "swap" procedure in Fortran 202x (a la std::swap in C++) that can swap arguments of *any type* on account of bureaucratic consideration the work-list had to be locked in essentially by early February of 2018 is of further shame. Intrinsic 'swap' in the Fortran standard will prove valuable no matter what form the future facility with generics takes in Fortran but this intrinsic can allow users to consider *generic* algorithms in their code by at least 2032 instead of 2045! e.g., a user can implement a quick sort routine with highly reduced code duplication to sort arrays of *any* type (with derived types, the user will likely have to provide the means to compare the types of course).

On the other hand, to say "one can do a lot with Fortran today" which is really saying the coders have to write LOTS and LOTS of code for the most basic and mundane of tasks - see below - is giving NO RESPECT whatsoever to any industry, particularly the time and labor of coders which are always the most valuable assets:

--- Example of RIDICULOUS code duplication with current Fortran ---

module m
! Dozens of lines of code for a 'generic' swap of processor-supported
! integer kinds and default real and logical and character (with further
! restrictions on length).

use, intrinsic :: iso_fortran_env, only : integer_kinds
implicit none
private
generic, public :: swap => swap_ik1, swap_ik2, swap_ik3, swap_ik4, swap_real, swap_char, swap_bool

contains

elemental subroutine swap_ik1( lhs, rhs )
! Argument list
type(integer(integer_kinds(1))), intent(inout) :: lhs
type(integer(integer_kinds(1))), intent(inout) :: rhs
! Local variables
type(integer(integer_kinds(1))) :: temp
! common instructions can be in an INCLUDE file
temp = lhs
lhs = rhs
rhs = temp
end subroutine
elemental subroutine swap_ik2( lhs, rhs )
! Argument list
type(integer(integer_kinds(2))), intent(inout) :: lhs
type(integer(integer_kinds(2))), intent(inout) :: rhs
! Local variables
type(integer(integer_kinds(2))) :: temp
temp = lhs
lhs = rhs
rhs = temp
end subroutine
elemental subroutine swap_ik3( lhs, rhs )
! Argument list
type(integer(integer_kinds(3))), intent(inout) :: lhs
type(integer(integer_kinds(3))), intent(inout) :: rhs
! Local variables
type(integer(integer_kinds(3))) :: temp
temp = lhs
lhs = rhs
rhs = temp
end subroutine
elemental subroutine swap_ik4( lhs, rhs )
! Argument list
type(integer(integer_kinds(4))), intent(inout) :: lhs
type(integer(integer_kinds(4))), intent(inout) :: rhs
! Local variables
type(integer(integer_kinds(4))) :: temp
temp = lhs
lhs = rhs
rhs = temp
end subroutine
elemental subroutine swap_real( lhs, rhs )
! Argument list
type(real), intent(inout) :: lhs
type(real), intent(inout) :: rhs
! Local variables
type(real) :: temp
temp = lhs
lhs = rhs
rhs = temp
end subroutine
elemental subroutine swap_char( lhs, rhs )
! Constraint: lhs and rhs must have same length
! Argument list
type(character(len=*)), intent(inout) :: lhs
type(character(len=len(lhs))), intent(inout) :: rhs
! Local variables
type(character(len=len(lhs))) :: temp
temp = lhs
lhs = rhs
rhs = temp
end subroutine
elemental subroutine swap_bool( lhs, rhs )
! Argument list
type(logical), intent(inout) :: lhs
type(logical), intent(inout) :: rhs
! Local variables
type(logical) :: temp
temp = lhs
lhs = rhs
rhs = temp
end subroutine
end module
program p
use m, only : swap
blk1: block
integer, parameter :: IP = selected_int_kind( r=2 )
integer(IP) :: a, b
print *, "Block 1"
a = 2_ip
b = 3_ip
call swap( a, b )
print *, "a = ", a, "; expected is 3"
print *, "b = ", b, "; expected is 2"
end block blk1
print *
blk2: block
integer, parameter :: IP = selected_int_kind( r=10 )
integer(IP) :: a, b
print *, "Block 2"
a = (2_ip)**42
b = (2_ip)**43
call swap( a, b )
print *, "a = ", a, "; expected is ", (2_ip)**43
print *, "b = ", b, "; expected is ", (2_ip)**42
end block blk2
print *
blk3: block
use, intrinsic :: iso_c_binding, only : IP => c_int
integer(IP), allocatable :: a(:), b(:)
integer :: i
print *, "Block 3"
a = [ 101, 102, 103 ]
b = [( a(i), i=size(a),1,-1 )]
call swap( a, b )
print *, "a = ", a, "; expected is ", [ 103, 102, 101 ]
print *, "b = ", b, "; expected is ", [ 101, 102, 103 ]
end block blk3
print *
blk4: block
real :: a, b
print *, "Block 4"
a = -99.0
b = 99.0
call swap( a, b )
print *, "a = ", a, "; expected is ", 99.0
print *, "b = ", b, "; expected is ", -99.0
end block blk4
print *
blk5: block
character(len=:), allocatable :: a, b
print *, "Block 5"
a = "foo"
b = "bar"
call swap( a, b )
print *, "a = ", a, "; expected is ", "bar"
print *, "b = ", b, "; expected is ", "foo"
end block blk5
stop
end program p
--- End example ---

Upon execution of the program compiled using a processor offering certain Fortran 2018 support such as enhancements to the GENERIC statement:

Block 1
a = 3 ; expected is 3
b = 2 ; expected is 2

Block 2
a = 8796093022208 ; expected is 8796093022208
b = 4398046511104 ; expected is 4398046511104

Block 3
a = 103 102 101 ; expected is 103 102 101
b = 101 102 103 ; expected is 101 102 103

Block 4
a = 99.00000 ; expected is 99.00000
b = -99.00000 ; expected is -99.00000

Block 5
a = bar; expected is bar
b = foo; expected is foo

[Richard Weed]

On Sunday, August 18, 2019 at 6:08:58 AM UTC-5, FortranFan wrote:
> On Saturday, August 17, 2019 at 9:19:15 AM UTC-4, Thomas Koenig wrote:
>
> > ..https://j3-fortran.org/doc/year/19/19-188.pdf does a pretty good
> > job (IMHO) pointing out what went wrong in other languages, and
> > what can be made better in Fortran as a result.
>
> To write the paper "does a .. good job pointing out what went wrong in other languages" is NOT right. Readers would do well to refer back to Steve Lionel's comment in the previous post, "I would hesitate to label things "correct" or "wrong". As I understand it, some approaches have limitations that didn't become apparent until some time after they were implemented. That doesn't make them wrong. (For an example of this from Fortran, look at FORALL.) "
>
>

Once again Fortran Fan echos many of the things that I and other "Joe Fortran Programmer"s (ie the Great Unwashed in the committees eys) think about the committee and the current standard development process. One point we do disagree on is the view that Fortran should try to be a general purpose language (and please correct me if I misread your statments along those lines). A chainshaw (AKA C++) can cut any kind of wood you want. However its not the best tool for doing finished carpentry like installing crown molding and quarter-round. A mitre saw or a coping saw (AKA Fortran) are better tools for that application. I agree (somewhat) that its better to wait a little and try to get generics right. Unfortunately, "wait a little" in the committees world means about 15 years and I think that is the biggest issue. If the committee is going to put off any decision on generics then I reiterate my request to spend some time looking at how they are used in real world scientific applications (mostly in written in C++) in areas like CFD and FEM. There are several open source projects where the code (of varying quality) is readily available. I think many members of the committee will be shocked to see that the world of scientific programming is no longer array centric as it was mostly in the "good old days". Modern algorithms in those areas rely heavily on unstructured mesh systems (due to the complex geometries they have to deal with) that don't map easily to an array. This makes ADTs like trees, lists, dictionaries etc along with sorting and searching algorithms a must if you don't (as Fortran Fan) want to waste time writting several thousand more lines of code than the average C++ or python programmer has to write. I went through the exercise a few years ago to write my own package of generic ADTs (circular lists, RB tree, hashMap, sets and generic qsort etc) using unlimited polymorphic objects to define generic containers. This started as an intellectual exercise to teach myself about the UP faciility in Fortran and just to see if I could do it. After about 3 months worth of work and several thousand lines of code that I would not have had to waste my time writting if an STL for Fortran existed, I ended up with a package that works for most smallish problems but I doubt it would be all that efficient for anything big. The biggest lesson I learned is that trying to do generics with just the UP facility is the wrong way to do it.

[Gary Scott]

On 8/18/2019 9:47 AM, Richard Weed wrote:
> On Sunday, August 18, 2019 at 6:08:58 AM UTC-5, FortranFan wrote:
>> On Saturday, August 17, 2019 at 9:19:15 AM UTC-4, Thomas Koenig wrote:
>>
>>> ..https://j3-fortran.org/doc/year/19/19-188.pdf does a pretty good
>>> job (IMHO) pointing out what went wrong in other languages, and
>>> what can be made better in Fortran as a result.
>>
>> To write the paper "does a .. good job pointing out what went wrong in other languages" is NOT right. Readers would do well to refer back to Steve Lionel's comment in the previous post, "I would hesitate to label things "correct" or "wrong". As I understand it, some approaches have limitations that didn't become apparent until some time after they were implemented. That doesn't make them wrong. (For an example of this from Fortran, look at FORALL.) "
>>
>>
>
> Once again Fortran Fan echos many of the things that I and other "Joe Fortran Programmer"s (ie the Great Unwashed in the committees eys) think about the committee and the current standard development process. One point we do disagree on is the view that Fortran should try to be a general purpose language (and please correct me if I misread your statments along those lines).

Strongly disagree. Fortran is already a general purpose language. All
many of us want is a tiny number of improvements.

[FortranFan]

On Sunday, August 18, 2019 at 10:47:28 AM UTC-4, Richard Weed wrote:

> .. One point we do disagree on is the view that Fortran should try to be a general purpose language (and please correct me if I misread your statments along those lines). ..


Whether with generics on this thread or with "a default IMPLICIT NONE" in a recent one, my comments are based on the feedback and reactions from young engineers who have done some work with me on Fortran but also leading computational technologists and managers who, even if they find a lot of good things in Fortran and are (somewhat) ok with the use of Fortran by individuals or teams for small programs/analysis tools/prototyping of ideas by subject matter experts, etc., will firmly oppose any use of Fortran for any major needs. Fortran currently is too feature-deficient for large-scale application development.

However the issue here in the context of generics is the apparent contradiction with the standard bearers: on one hand, the Fortran standard and the "official" position (or lack thereof) steer Fortran in the direction of a general-purpose language, however almost all the actions "speak" otherwise, that it is to be treated as a language kinda "optimized" toward a certain approach to "scientific and technical programming". And its user base too is mostly the latter.

So my view then is to first pay attention to the feedback of leading computational technologists and managers and also the needs of immediate practitioners of Fortran and look for convergence. Large-scale application development these days and also the Fortran users' input, as captured in the WG5 survey, both clearly indicate a strong need in generics, explainable perhaps by the comments of Richard Weed and others with respect to the need to employ abstract data types in so much of modern code. And one can also notice a *certain overlap in their use cases* as to whether they belong to the realm of general-purpose programming or domain-specific with numerical computing. This is borne by the fact even the applications specialized toward "scientific and technical programming" domains need to exchange data, and lots and lots and lots of it now, with other humans and systems and pre- and post-processing of numerical data are too important to be ignored. Generics become extremely, extremely important in such a scenario.

So yes, one has to think more broadly with generics in Fortran but not so much that one keeps delaying the development. Generics is by no means cutting-edge research in Comp. Sci., it's mostly a "solved problem" from decades ago. One cannot then take another 15-20-25 years for the facility to materialize in Fortran.

[Richard Weed]

I guess my issue with the words "general purpose" implies you could write a compiler with Fortran (assuming it was brought up to the leval of C++ etc). I don't think its somthing you would want to do if you could.

[Thomas Koenig]

Richard Weed <rwee...@gmail.com> schrieb:

> I guess my issue with the words "general purpose" implies you
> could write a compiler with Fortran (assuming it was brought up
> to the leval of C++ etc).

I think I can speak with a bit of authority if I say "Of course you
can". You don't even need the object-oriented features of Fortran 2003
and following, although they would make a few things easier.

> I don't think its somthing you would want to do if you could.

Why not? If I wanted to start a Fortran compiler from scratch,
Fortran would not be a particularly bad language.

The main reason that the gfortran front end is written in C (well,
a severely curtailed version of C++) is that its predecessor, g95,
started out as a separate back end to gcc, so it was natural to
write it in C. Also, nobody sees a value in rewriting gfortran
in Fortran just for the sake of doing something differnt.

It is possible to write a gcc front end in its own language (see
Ada), but the need to interface to the gcc middle end remains.

[ga...@u.washington.edu]

On Sunday, August 18, 2019 at 11:00:50 PM UTC-7, Thomas Koenig wrote:

(snip on Fortran compilers written in Fortran)

> Why not? If I wanted to start a Fortran compiler from scratch,
> Fortran would not be a particularly bad language.

> The main reason that the gfortran front end is written in C (well,
> a severely curtailed version of C++) is that its predecessor, g95,
> started out as a separate back end to gcc, so it was natural to
> write it in C. Also, nobody sees a value in rewriting gfortran
> in Fortran just for the sake of doing something differnt.

> It is possible to write a gcc front end in its own language (see
> Ada), but the need to interface to the gcc middle end remains.

The IBM OS/360 Fortran H compiler is about half written
in Fortran H. (Include the PARM='XL' feature allowing for
bitwise logic functions.) As well as I know it, the logic
related to doing optimizations is much of the Fortran part.
Low-level I/O, and I suspect things like parsing are in assembler.

Among others, writing the optimizer in Fortran means that it
can speed up itself. At the time, there weren't so many other
choices, about 10 years before C.

On the other hand, it isn't unusual to write parts of compilers
in a single-purpose language specific to the need, and also a
program to convert to the desired language. Code generators
often have the available operations in a convenient form, which
compile into tables for table-driven generators. This could also
be done for other parts of a compiler.

[FortranFan]

On Sunday, August 18, 2019 at 6:39:27 AM UTC-4, David Duffy wrote:

> But unless one is taking the C# approach, this always happens anyway at
> the level of the executable code doesn't it? It is tedious, but there
> are several Fortran metaprogramming tools that can automate this, none
> of which seems particularly popular.

> ..

Based on what I see, a huge reason why "several Fortran metaprogramming tools" are not popular is because they are NON-STANDARD, there is nothing to "back them up" in any way, the tools can come and go, they can continue to function superbly or do a few things alright but not other or very poorly or break altogether at any point, they are quintessential vapor-ware. Starting with Fortran 90, a foundation has been built around ISO IEC Standard for Fortran that has eased much of the portability and maintenance issues during the 70s and 80s and early 90s with various dialects of FORTRAN (IV, 66/77, etc.) plus extensions. But now if the Fortran standard cannot support a significant need such as generics that is otherwise part-and-parcel of other programming languages these days, then the whole edifice of the standard will start to fall apart

> I am pretty ignorant about compiler implementation, but to
> make their generics so performant the C# runtime seems to have
> particular properties. The most obvious is JIT compilation supporting
> new instances of a generic, but I guess garbage collection may be
> necessary to assist such an approach. Would that mean that a flavour

> of Fortran supporting this might only be one compiler or platform? ..

Hopefully readers who are not "ignorant about compiler implementation" can provide useful comments. Re: "Would that mean that a flavour of Fortran supporting this might only be one compiler or platform?," I really do not think that will be the case.

From what I see, garbage collection (GC) is of no *added* relevance to the aspect of generics in C# (or Visual Basic.NET which is essentially equivalent to C# for the purposes of this discussion). GC is integral to Java and C# and the situation in these languages is akin to someone writing code in Fortran giving all variables - in ALL SUBPROGRAMS including its local variables, modules, everywhere - the ALLOCATABLE attribute; a Fortran processor will effectively end up doing a lot of garbage collection with such code. Starting with Fortran 2003, this aspect has been addressed reasonably well; no need for anyone to bring GC to derail this thread, it's mostly a separate matter.

What is important in the context of generics with .NET i.e., C# and Visual Basic is that additional information gets added to the MSIL (Microsoft Intermediate Language) to which generic code (say, a parameterized function like the SWAP procedure mentioned earlier) gets transformed and then when the caller code includes a specific type instance e.g., 'Swap<int>(a, b);', it gets transformed based on a specialized instance of the function, effectively providing a developer with compile-time type-checking. Conceptually the approach is no different than anything that was on the anvil during the 1990s for Fortran 2000 (which later became Fortran 2003) with parameterized modules and procedures even if some of the details differ.

The questions really are about having a will (there will be a way then) to do generics in Fortran and to be really open-minded to *successful* and practicable approaches, in which case those interested must look closely at Microsoft.NET and C#/Visual Basic for Generics.

Note Fortran 2003 eventually ended up with parameterized derived types (PDTs) but with integer KIND-based and LENgth-based parameterization only.

Where C#/Visual Basic can help is with providing first some clues and concepts on high-level syntactical aspects to BUILD UPON the PDT concept as well as with other existing generic aspects in Fortran (e.g., generic interfaces) to extend to the use cases of interest to Fortranners which is primarily parameterized derived types (i.e., beyond current PDT) to facilitate abstract data types (ADT) and ADT calculus as well as parameterized procedures (e.g., generic SWAP, generic FINDLOC, generic SORT, etc.).

But more importantly, C#/Visual Basic can then also provide some semantical guidance on how to make truly parameterized derived types and procedures practical for Fortran compilers as well as its users e.g., with the way constraints are used in C# using its 'where' construct.

[dpb]

On 8/18/2019 6:08 AM, FortranFan wrote:
...

> 1) On one hand the ISO IEC standard is entirely silent on the above 2 questions but unabashedly presents Fortran as some general-purpose language for everyone for everything, including for unicorns for the purpose of making skittles!
>
> 2) On the other hand, every decision and direction taken by the committee has to satisfy the interests of certain TENURED institutional reps toward a few long-standing programs toward particular applications in so-called scientific and numerical computing and their suppliers, the compiler vendors, who only see certain limited returns on their efforts with Fortran language and thus are inclined to adopt minimalism and where "performance and backward compatibility", like industrial SAFETY post-Bhopal in chemical industry, are wielded like the double-edged sword: one can "kill" any and all feedback from ordinary practitioners with these 2 undeniable notions OR when a clique forms with a strong interest in something like SPMD with PGAS approach using COARRAYS, one can sell any idea using such considerations even if the work can be of little benefit to so many in the computing world where Fortran is mostly in a few libraries and that "single program" in SP can be anything but a Fortran main program i.e., a 3rd-party simulator, a spreadsheet program, a web browser, some opaque thingy running on the cloud, ...
>
> All the while, the computing world keeps advancing rapidly but where
>
> NO LARGE, NEW programs, worthy of any consideration especially in industry, get developed in Fortran, period.
>
> The above points are especially important in the case of generics: because if Fortran is truly intended to be a general-purpose language for a wide variety of applications as mentioned in point 1, then considerations involving any issues faced by the practitioners of C++ and Java might become meaningful.
>
> However, like with everything else particularly OO, if Fortran is immediately predisposed to including only the MINIMUM facilities in the language for specific needs as envisioned by those reps with their "scientific and numerical computing" applications with considerations of "performance and backward compatibility", then why go around bad-mouthing C++, Java, etc. at all? That is, when the "scientific and numerical computing" developers using these other languages mostly adopt a small set of the Templates/Generics features of these languages where the stated issues such as in paper 19-188 are of little relevance.
>
> Separately, readers here and especially WG5 (should it be serious about generics) will take take note there is a language system and an implementation framework that gets *GENERICS just about RIGHT* and that is Microsoft with their .NET system and C# and Visual Basic languages.
>
> C# and Visual Basic are reasonably close to efficient and practicable examples of languages that draws from the best of other languages such as C++ and Java, adopts aspects that fit well with their existing platforms, and solves major issues faced earlier by their programmers. C# and Visual Basic find ever-increasing applications, especially in industry, in many domains including the "scientific and numerical computing" ones.
>
> So what would it take for WG5 to take a close look at generics in Microsoft C#/Visual Basic.NET? I ask given the tacit and persisting bias I notice against Microsoft's solutions by many, one which can be especially VIRULENT among the academia (it's rather strange the lead author of paper 19-188 makes no reference to either C# or Visual Basic in that paper) but also by certain influencers in connection with Fortran. It appears an uphill battle, nearly an impossible one, to "market" .NET languages successfully as only examples to look at and to give them a basic (pun intended) level of consideration toward feature development in Fortran.

...

I'd think the best way to help resolve all of those would be to become
involved directly w/ WG5 rather than just carping and casting stones
from the outside.

Clearly, unless others than vendors and those institutional reps whoever
they might are involved, the viewpoints they have are those that they
have knowledge of and probably the other viewpoints you espouse are less
familiar to them.

There's a much smaller community for Fortran vis a vis C/C++ and MS has
the right to do things as they see fit w/ their proprietary languages so
it's not at all surprising to me the others proceed more rapidly even if
the seriousness with which compatibility is considered with Fortran were
not so prevalent.

--

[Harold Stevens]

In <qjf386$1h4l$1...@gioia.aioe.org> dpb:

> On 8/18/2019 6:08 AM, FortranFan wrote:

[Snip ...]

> rather than just carping and casting stones from the outside

+1

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

[steve kargl]

dpb wrote:

> On 8/18/2019 6:08 AM, FortranFan wrote:
> ...
>
>> 1) On one hand the ISO IEC standard is entirely silent on the above 2 questions but unabashedly presents Fortran as some general-purpose language for everyone for everything, including for unicorns for the purpose of making skittles!
>>
>> 2) On the other hand, every decision and direction taken by the committee has to satisfy the interests of certain TENURED institutional reps toward a few long-standing programs toward particular applications in so-called scientific and numerical computing and their suppliers, the compiler vendors, who only see certain limited returns on their efforts with Fortran language and thus are inclined to adopt minimalism and where "performance and backward compatibility", like industrial SAFETY post-Bhopal in chemical industry, are wielded like the double-edged sword: one can "kill" any and all feedback from ordinary practitioners with these 2 undeniable notions OR when a clique forms with a strong interest in something like SPMD with PGAS approach using COARRAYS, one can sell any idea using such considerations even if the work can be of little benefit to so many in the computing world where Fortran is mostly in a few libraries and that "single program" in SP can be anything but a Fortran main program i.e., a 3rd-party simulator, a spreadsheet program, a web browser, some opaque thingy running on the cloud, ...
>>
>> All the while, the computing world keeps advancing rapidly but where
>>
>> NO LARGE, NEW programs, worthy of any consideration especially in industry, get developed in Fortran, period.
>>
>> The above points are especially important in the case of generics: because if Fortran is truly intended to be a general-purpose language for a wide variety of applications as mentioned in point 1, then considerations involving any issues faced by the practitioners of C++ and Java might become meaningful.
>>
>> However, like with everything else particularly OO, if Fortran is immediately predisposed to including only the MINIMUM facilities in the language for specific needs as envisioned by those reps with their "scientific and numerical computing" applications with considerations of "performance and backward compatibility", then why go around bad-mouthing C++, Java, etc. at all? That is, when the "scientific and numerical computing" developers using these other languages mostly adopt a small set of the Templates/Generics features of these languages where the stated issues such as in paper 19-188 are of little relevance.
>>
>> Separately, readers here and especially WG5 (should it be serious about generics) will take take note there is a language system and an implementation framework that gets *GENERICS just about RIGHT* and that is Microsoft with their .NET system and C# and Visual Basic languages.
>>
>> C# and Visual Basic are reasonably close to efficient and practicable examples of languages that draws from the best of other languages such as C++ and Java, adopts aspects that fit well with their existing platforms, and solves major issues faced earlier by their programmers. C# and Visual Basic find ever-increasing applications, especially in industry, in many domains including the "scientific and numerical computing" ones.
>>
>> So what would it take for WG5 to take a close look at generics in Microsoft C#/Visual Basic.NET? I ask given the tacit and persisting bias I notice against Microsoft's solutions by many, one which can be especially VIRULENT among the academia (it's rather strange the lead author of paper 19-188 makes no reference to either C# or Visual Basic in that paper) but also by certain influencers in connection with Fortran. It appears an uphill battle, nearly an impossible one, to "market" .NET languages successfully as only examples to look at and to give them a basic (pun intended) level of consideration toward feature development in Fortran.
> ...
>
> I'd think the best way to help resolve all of those would be to become
> involved directly w/ WG5 rather than just carping and casting stones
> from the outside.

No kidding.

I nominiate Vipul Parekh and Richard Weed as co-chairs to write a
TS for generics in the vain of TS 29113, " Further Interoperability of
Fortran with C" and TS 18508 "Additional Parallel Features in Fortran"
to present to J3/WG5. This will allow Vipul Parekh and Richard Weed
to fast-track generics into the standard. Vipul Parekh is a member of
the J3 mailing list, so he should be able to get adequate guidance
on how to proceed.

How did JFK put it? "Ask not what your Fortran Standard committee
can do for you, ask what you can do for your Fortran Standard committee."

--
steve

[FortranFan]

On Monday, August 19, 2019 at 5:10:35 PM UTC-4, dpb wrote:

> >>
> I'd think the best way to help resolve all of those would be to become
> involved directly w/ WG5 rather than just carping and casting stones
> from the outside.
>

SHEER NONSENSE. @dpb posts absolutely the wrong way to look at the situation, the only thing that matters here is Fortran which is losing out in so many areas and domains. This is nothing personal. Calling it as someone sees it first hand can ultimately only help Fortran and its practitioners.

So anyone thinking along the lines of @dpb should first read honest input by Richard Weed here:
https://groups.google.com/d/msg/comp.lang.fortran/CYPcCyu7PQ4/S_j7BMM7BwAJ

"If I told my boss I wanted him to pay for a trip to Las Vegas to participate in a Fortran standard committee meeting he would kick me out of his office"

and note that this is someone who has been trying to work directly - so have put in a few hard miles already but at enormous personal cost and job risk with participation in 3 meetings now.

All Fortran fans will find, I surely do, @Steve Lionel made a most admirable and progressive initiative in seeking user feedback via WG5 survey and by openly sharing the results: see N2147 document https://isotc.iso.org/livelink/livelink?func=ll&objId=19530634&objAction=Open&viewType=1

And the feedback by users was overwhelmingly in support of Generics in Fortran 202x. Generics got the highest ranking in the feedback. Yet it got dropped. The "what" of the decision i.e., to drop Generics is still somewhat palatable: ok so WG5 couldn't quite "cross the bridge" when it came to the challenge (as with many other things in Fortran 202x). But the issue here really is "how" - there are just way too many things which are questionable - and I have not even scratched the surface - that can lead to repeat scenarios where ordinary users of Fortran go unheard, facilities that could be of use to them get delayed and thus denied, and Fortran becomes less and less competitive.

> ..

> There's a much smaller community for Fortran vis a vis C/C++ and MS has
> the right to do things as they see fit w/ their proprietary languages so
> it's not at all surprising to me the others proceed more rapidly even if
> the seriousness with which compatibility is considered with Fortran were
> not so prevalent.

> ..

Why not be honest and look at all possible factors: perhaps the differences have to do with attitude and priorities also? At one time, C++ community was infinitely smaller than that of Fortran. Same with Python. With C++, Stroustrup always tries to do the most in terms of introducing features as fast as possible for its users, fully realizing the importance of facilities that coders need as computing advances. Stroustrup's initiative inspires others to do the same for C++. Same goes with Python and van Rossum. But yes, these languages are not without problems.

However users of Fortran with their feedback, like in the WG5 survey, show TREMENDOUS RESTRAINT and use GREAT DISCRETION already by only asking for certain key features that have proven valuable e.g., few, if any, ask for multiple inheritance with OO in Fortran just because C++ has it but they request generics because the use of derived types, among other factors, call for it. Yet Fortranners will have to wait for decades now. Perhaps things could have been improved greatly by other ways to collaborate as I suggested here:
https://groups.google.com/d/msg/comp.lang.fortran/CYPcCyu7PQ4/VwPt-DsoBwAJ

Comments by @dpb such as "carping and casting stones from the outside" is a total mischaracterization of reality and a disservice to Fortran.

--- Summary of user feedback on Generics in WG5 survey document N2147 ---
Generic Programming or Templates
Score: 6.21

• Reduce the tedious generation of almost identical code for various datatypes. Reducing scope for errors by not having different versions of the same routine for different types hidden behind an interface.

• Have made use of templating in C++. Should be possible to make Fortran equivalent lighter and easier to use (if less powerful).

• I've used the facility in C++, C# and Java. The first example Jane and I use in our teaching (and book) is based on sorting, and we provide 3 real and 4 integer implementations of the same sort algorithm. The second example implements a generic statistics module for 32, 64 and 128 bit reals. If a template facility existed in Fortran we would add generic container examples to our books and teaching.

• I went to the extent of writing my own SED/AWK preprocessor to handle templated source code. Obviously, I would prefer to have a standard solution, but it has to be really usable, and it has to play nicely with my OO code.

• Generic programming and templates will simplify much the structure of the code, avoiding redundancy when the same routine is used for different kinds of variables. I currently use this feature in C++ programming

• 1. No needs to write subroutines for different kinds, fixed size for vectors inside types (parmeterized derived types, implemented in some compilers is terrible concerning execution time). 2. Yes.

• I would regard templates to be a boon simply to keep repeated code for different types to a minimum. Some of the suggestions that have appeared on clf are interesting for their syntactic simplicity. In doing a little bit of research on templates, I kept coming across the remarks that D templates are syntactically sweeter than C++. On reading the D template Tutorial by P Sigaud (206 pages!), I think that I will start eating lemons.... KISS must rule. My preference would be something along the lines of a generic type declaration to mirror/supplement the existing generic language features. Once SELECT TYPE is rolled in, a highly flexible language extension would have been enabled, which fits in nicely with existing Fortran features. By not insisting on dynamic dispatch of instances of templated procedures, implementation would be straightforward too. It is time that iterators made their way into Fortran. Not only could these provide syntactic advantages and improved flexibility compared with DO but then the way would be open to the provision of a standard library like STL. Again, KISS must be kept in mind!

• Template like feature can be used with subroutine in F95, but with OOP coming in, I would like polymorphic templates for many applications. I am not an OOP man, so more comment may not be possible. F95 had many indirect ways of doing things, but making cleaner fast methods would help.

• 1. It could save a lot of typing 2. I use it in C++ and Java programming

• Many times, I'm writing the same routine for different types, or different kinds. I used templates and STL containers in C++. I would like to see them in Fortran too. A sort of move semantic should then be also implemented.

• Quite often, we have to write multiple versions of each wrapper wherein the only difference between the versions is in the type of the first argument. All else in the procedure remains the same.

• Fortran really needs support for generic programming and generic data structures and algorithms. Something like C++ templates and the standard template library would be ideal, whether provided as intrinsic (compiler-provided) modules or as user-written code. Users should not need to implement common data structures like linked lists or binary trees themselves, then have to cook up a way (invariably using nonstandard preprocessing and/or abuse of the IMPLICIT statement) to avoid duplicating code for each type they want to use with the data structure

• It would allow the community to implement a library of containers, like C++'s STL. Right now something like that can only be done by abusing the C-preprocessor (see for example https://github.com/robertrueger/ftl), which is not exactly pretty and requires manual template instantiation. Even people who never write templates themselves would benefit a lot from these template libraries, so I think it is really the single most important thing missing in Fortran.

• IMHO, the most annoying missing feature in Fortran is generic containers, i.e., the tools to construct and use lists, stacks, trees, etc. without reference to the type of the elements, but nevertheless type-safe at all stages. A significant fraction of our code, regarding data management at any level, could be written more clearly, readable, and concise. To a lesser extent, this applies also to generic algorithms such as sorting. Partly for that reason, we use OCaml for algorithms that require formal, non-numerical manipulation of data structures. OCaml is a strongly typed functional language that supports type-parameterized types (such as "list of type x") and type-parameterized modules (a.k.a. functors) in a very straightforward and entirely type-safe way. If such facilities had been available in Fortran, coding such algorithms in Fortran - not just the numerical parts - would have been a viable alternative.

• Writing generic code is painful and tedious. If it were easier, I would actually bother writing reusable modules for lists, trees, etc. to use in my projects. Currently, it's too much trouble.

• c++ template meta programming

• Templates remove lots of duplicate coding. I used this extensively in C++.

• It is a feature that is often asked for (judiging from the number of reads of an old Fortran Forum article of mine on the subject. I should really re-write it, as it is antiquated, even without formal templates in F2020). I have seen it used in languages like Java and C#, especially with respect to data containers like lists. It would help with libraries in various precisions.

• Adding generic programming would significantly simplify the creation of containers. At present, a container has to be written for every type it is desired to contain. This means large sections of code have to be repeated, e.g. a numeric linked list has to be coded for types integer, real(dp) and complex(dp) at a minimum, not to mention writing a linked list of user defined types. The ability to define types (in C++ syntax) as container<T>, rather than container_integer, container_real etc. would reduce this to a single definition for each container. I have used these features extensively in C++, although I feel that Rust does a better job of implementing them.

• Easily making overloaded double and single types of functions without duplicating code. Being able to have functions like "optimise(f, anyobject)" which will work by calling f(x, anyobject) where anyobject is any type containing extra data used by f (without requiring tiresome redundant select type.. statements inside f).

• A lot of algorithms are applicable to a wide variety of data types or kinds of a particular data type. Using current features, a programmer has to write the procedure implementing the algorithm over again for each data type and kind that the algorithm is implemented in. This requires a tremendous amount of wasted time and effort and many opportunities for making mistakes in one or more implementations of the same algorithm. Implementing procedure
templates would greatly reduce or eliminate this duplication and opportunity for defects. Therefore the benefit-to-cost ratio to application developers of this feature is tremendous.

• I have written many containers to provide e.g. lists, sets and maps. To do this and avoid large amounts of copied code I have used the c-preprocessor so that they can be used with integer(2,4,8) read(4,8). This really seems to me to be a deficiency in the language. I don't think that the extensive way C++ has taken templated is the right way but some form of template functionality is a must. It would also enable STL to be incorporated into Fortran, after all it wasn't originally created for C++ it was just incorporated by it. Containers (including iterators) are a natural way to program and it would be really nice if Fortran supported these paradigms directly rather than through to cpp.

• Generic programming and/or templates is something that seems to get implemented in every Fortran project through some other language (e.g. Python, Ruby or even IDL!). It is very often the case that we need to perform exactly the same operation on arrays of rank 1, 2, 3, etc., or arrays of different types -- e.g. I/O using an external library. The only way to avoid writing the same thing over and over again is through some nature of templating. The current universal polymorphic stuff does come in handy, but the requirement for type guards makes the code a) much uglier and b) much less useful. I use this all the time in other languages, either explicitly using templates as in C++, or "duck-typing" in Python.

• Reduce duplicate and boilerplate code leading to increased maintainability and flexibility. This feature has proved very useful in applications written in other languages.

• It will let me and others implement resuable code. It will let us write a generic "collections" library, for example.

• Generic programming or templates a'la C++ will definitely help me to better express some of the abstract data types in my projects. For example static polymorphism of templated containers like std::vector and std::valarray in C++ where the same class interface(procedure signatures) is presented to user class.

• Generics would help avoid writing redundant code that differ only by argument type (i.e. single- and double precision versions of the same function; data structures such as hash tables, trees, and linked lists)

• An FTL like the C++ STL would be quite useful. While I agree that static programming is easier to understand, generic programming can be more flexible.

• The code I work on makes extensive use the C pre-processor in places to create generic versions of Fortran procedures via macros. Or we just write the code in C++... Unfortunately, the current Parameterized Derived Type facility, even if it were implemented by a majority of compilers, is insufficient for our use.

• It would allow reuse of code. For example, a generic function for resizing an array would be very useful. I use generic programming extensively in OCaml via parametrized modules.

• A generic list implementation is really lacking and this is not fully solved with unlimited polymorphism

• Generic lists facilitate the book-keeping of a lot of applications.

• I have several procedures in various kind versions. Templates may allow one procedure for various kinds. I use this feature frequently in C++

• It would dramatically simplify the programming of generic algorithms. I currently have to use a preprocessor with many shortcomings.

• Reusing the same code for different data types. Parameterized modules are fine for me.

• We already implement template programming on our own. This would eliminate our need to do this by hand on our own, with complex scripting and build mechanisms. Having this built into the language would make this much easier.

• I could write generic containers, like lists, once and not have to keep writing nearly identical code, or resort to ugly use of source pre-processing with includes and macros to automate the source code generation. I've worked some in C++ and found this to be incredibly useful.

• Generic programming is the fundamental key to achieve a real Abstract Calculus by means of which mathematical/physical programs achieve high conciseness, clearness, easy maintainability and flexibility allowing to develop generic libraries the API of which strongly resemble high-level math expression. I used generic programming in Python.

• Writing the 10000th routine for sort, linked lists, ... is tedious and error-prone - reinvented wheels are all too often square. But beware the complexity - it is easy to mess up (as C++ did) and create a Turing-complete language by accident.

• I have used generic programming when working on Java codes. It is definitely a very useful feature that allows to avoid a lot of code duplication and simplifies code structure a lot. I would be hesitant to follow C++ example, though, templates seem to be much more difficult to use correctly than Java generics.

--- End summary ---

[steve kargl]

FortranFan wrote:

> On Monday, August 19, 2019 at 5:10:35 PM UTC-4, dpb wrote:
>
>> >>
>> I'd think the best way to help resolve all of those would be to become
>> involved directly w/ WG5 rather than just carping and casting stones
>> from the outside.
>>
>
> SHEER NONSENSE.

Vipul Parekh,

Get off the side line. Why do you continually harp on
what J3/WG5 should do for you, when you show zero
willingness to actually get involved and help do the
heavy lefting? Do you think the modifications to the
Fortran standard simply come out of thin air?

Write up a TS. Be a hero to the Fortran World.

--
steve

[Arjen Markus]

On Tuesday, August 13, 2019 at 8:58:39 AM UTC+2, Arjen Markus wrote:
> On Monday, August 5, 2019 at 10:24:26 AM UTC+2, Steve Lionel wrote:
> > On 8/3/2019 10:17 PM, Richard Weed wrote:
> > > I went to the J3 web site (www.j3-fortran.org) to start going back over all the documents from the past few revision iterations to see if any of the ideas for modifications to Fortran I have were previously considered. I ran across the following paper "Reflecting on Generics for Fortran" by Haveraaen, Jarvi, and Rouson.
> >
> > Haveraaen and Rouson are here at the WG5/J3 meeting this week, and we
> > intend to discuss the paper.
> >
> > --
> > Steve Lionel

> > Retired Intel Fortran developer/support
> > Email: firstname at firstnamelastname dot com
> > Twitter: @DoctorFortran
> > LinkedIn: https://www.linkedin.com/in/stevelionel
> > Blog: http://intel.com/software/DrFortran
>

> I read this paper with interest. What is even more interesting is that a lot of what they present can already be achieved with Fortran as it is. (Yesterday evening I completed encoding my experiment with generic features. Not yet my note, though, describing what I did :). So That Should be Completed Real Soon)
>
> Regards,
>
> Arjen

Okay, here is a draft version of the note: http://flibs.sourceforge.net/generic_programming_features.pdf, with the accompanying code at https://sourceforge.net/p/flibs/svncode/HEAD/tree/trunk/experiments/generics/.

I am certain not everybody will be enthousiastic about the solution I came up with and I agree that some of it is clumsy or could be improved, but it does show what can be done already and that was my main purpose.

Regards,

Arjen

[Steve Lionel]

On 8/20/2019 1:46 AM, FortranFan wrote:
> And the feedback by users was overwhelmingly in support of Generics in Fortran 202x. Generics got the highest ranking in the feedback. Yet it got dropped.

No, it didn't.

[FortranFan]

On Tuesday, August 20, 2019 at 9:15:39 AM UTC-4, Steve Lionel wrote:

On 8/20/2019 1:46 AM, FortranFan wrote:
> And the feedback by users was overwhelmingly in support of Generics in Fortran 202x. Generics got the highest ranking in the feedback. Yet it got dropped.

> ..
> No, it didn't. ..

I presume the "No" is with respect to my comment about "dropped" which I only meant in terms of Fortran 202X i.e., given the earlier statement, "At last .. WG5 meeting, .. it was .. felt that it was too big a feature to try to get done for Fortran 202X"

[dpb]

True. But, one might hypothesize that w/ more participation in WG5 so
there was a larger complement amongst which to distribute the workload
that it might not have seemed quite so large, particularly if those were
to include some directly interested and knowledgeable to contribute
meaningfully.

--

[James Van Buskirk]

"FortranFan" wrote in message
news:726d1005-e8b6-4dee...@googlegroups.com...

> With modern C++, a young coder will simply do:
> std::swap(x, y);

For a quicksort, the items to be swapped reside in the same array, so
A([I,j]) = A([j,i])