(j3.2006) (SC22WG5.5869) [ukfortran] N2126

Clune, Thomas L. GSFC-6101 thomas.l.clune
Tue Jun 6 08:34:55 EDT 2017


On Jun 5, 2017, at 6:04 PM, Bill Long <longb at cray.com<mailto:longb at cray.com>> wrote:



<deleted other part of the thread>

A comment on Van?s post earlier in the thread:

Van said:

People aren't rushing from Fortran to C++ to get the C preprocessor.
They want templates (which were called generic packages in Ada in 1983).


People used to rush to C++.  People who are in their 50?s still think this is happening.  The new set have switched to the Python religion.   The lesson is to not put too much emphasis on fads.

I don?t think this characterization is very accurate either.    There continues to be a large volume of developed and maintained C++ code that targets performance for complex applications.    Presumably most such developers also know a fair bit of python as it is a good choice in other situations.    E.g., it is often used as a glue layer for Fortran and C.      I think characterizing either of those languages (or Java for that matter) as ?fads? does a disservice to those communities and intimates that the committee is a bit blind to the world outside of Fortran.


That said, Van rightly points out that templates are popular.  Anyone who has written long lists of specific functions for a generic interface knows that there should be a better way.  With  F2015  features available, I think we can pretty easily specify a Fortran template capability that is clean, simple to use, and simple to implement. We finally have a decent starting point.  And we don?t have to fall into traps like grafting on big chunks of another language, or the unreadable macro facility that we abandoned before.

I look forward to those discussions!

Cheers,

- Tom




Cheers,
Bill



Keith Bierman
khbkhb at gmail.com<mailto:khbkhb at gmail.com>
303 997 2749

On Mon, Jun 5, 2017 at 2:19 PM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov> wrote:
Van,

I see this as a perfect explanation of why use cases _are_ very important.   (And possibly a demonstration that decisions made by committees should not be expected to be perfect in every instance. What a surprise!)

I have several different use cases  that would be satisfied by some type of generic programming feature.      But not all generic programming features would satisfy all of my use cases.      With the use cases in hand, the committee can make trade-offs between complexity if implementation and the perceived importance of the various use cases.      For example, one of my big use cases is for ?containers?  (ala C++ STL).       If this were the only use case, then one possible solution would be to introduce new container types: Vector, Set, Map, ?     This would hardly count as a general-purpose approach to generic programming, but would nonetheless provide some very useful functionality.    Alternatively, some sort of templating mechanism would be more general purpose, but would probably not easily handle some of the edge cases I have and certainly would require more effort on the part of the end user to implement the logic for robust containers.

Note - I?m not intending this as a platform to argue for or against generic programming or a particular choice of feature for such.  This is just meant to illustrate the value of use cases.

Cheers,

- Tom



On Jun 5, 2017, at 3:16 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

On Mon, 2017-06-05 at 12:45 +0000, Clune, Thomas L. (GSFC-6101) wrote:
widely available, and widely used,
in other high level languages - is that not a use case?

Not an argument that generally gets much sympathy in this committee.
Just work it backwards - why were those features widely used in the
other languages?

People aren't rushing from Fortran to C++ to get the C preprocessor.
They want templates (which were called generic packages in Ada in 1983).
We briefly considered parameterized modules, then macros, then
essentially no support for generic programming.

Both Ada and C++ supported generic programming from their origination,
so it's not a new untried mystery.

If we had had parameterized modules, it is unlikely we would have done
parameterized derived types -- at least not with kind parameters.  And
we wouldn't have ended up with the disconnect between parameterized
types and type-bound procedures that Richard Maine warned about twenty
years ago.


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

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

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

Bill Long                                                                       longb at cray.com<mailto:longb at cray.com>
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170606/530d450c/attachment-0001.html 



More information about the J3 mailing list