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

Bill Long longb
Mon Jun 5 18:04:16 EDT 2017


> On Jun 5, 2017, at 3:26 PM, Keith Bierman <khbkhb at gmail.com> wrote:
> 
> I don't recall the committee being against use cases as such.

It?s not against use cases in general.  But some judgement is needed.  Poor examples of use cases might include

1) Code X was poorly designed from the beginning, and this new feature would help bail the user out of the hole he dug. 

2) This is a cool thingo even though using it would result in horribly performing code.  [Keeping in mind that Fortran is, basically, the only language purpose designed for HPC.]

3) If we had this feature then I could write a code like this other language, even though Fortran already has a better way to do the same thing.


> 
> The tension has always been between what "users" are perceived to want and what implementors are able to (practically, subject to Management/funding/etc.) deliver. 

Agreed.  And the number of active implementors seems to continue to decrease. 

> 
> I believe Steve made an excellent point about the pragmatics ... few sensible organizations are willing to commit to using features which aren't supported by multiple compilers. Few vendors are currently fully funding Fortran compiler development (and code quality/performance tends to have a much higher perception as being critical customer satisfiers to most Management chains).

I have the same experience with (most) customers wanting multiple compiler vendors.  With fewer vendors out there, the minimum number of conformers may have to drop.   

> 
> Obviously there's a feedback loop; when there are few perceived paying customers, there tends to be less funding, which may well drive customers away.

Unfortunately this seems to be true. 

> 
> Sorry, I don't have any magic wand or beans to make life easier ;<
> 

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. 

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. 

Cheers,
Bill



> Keith Bierman
> 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
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





More information about the J3 mailing list