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

Clune, Thomas L. GSFC-6101 thomas.l.clune
Mon Jun 5 08:45:34 EDT 2017

> On Jun 5, 2017, at 5:16 AM, Anton Shterenlikht <mexas at bris.ac.uk> wrote:
>> From: John Reid <John.Reid at stfc.ac.uk>
>>> Or is it an ivitation to comment?
>>> If so, I have some comments.
>> I don't think these are mutually exclusive. Commenting would be good.
> ok.
> I read this very long paper.
> I think the tone is a bit
> too downcast and pessimistic.
> Budgeting is a great idea,
> but I doubt WG5 was not budgeting before,
> at least in some sense.
> Most successful projects go
> over budget - something about
> human nature I believe.
> Focussing on use cases is a great idea,
> but presumably all proposers of new features
> always had some supporting use cases behind?

I was not there, but I suspect many ?desired? features were in the ?Look at this shiny baubel!? category.    But more to the point, by using actual use-cases, subcommittees can more intelligently design features that possibly solve multiple use cases simultaneously.    Use cases can also be used to build consensus.   E.g., I may not immediately see the value of feature X, but if the use case resonates with a coding frustration I?ve experienced in the past, my interest may be significantly piqued.

> What about a demand to have features
> 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?    E.g.,  Exceptions are desirable, not because C++, Python, Java, ? all have them and are routinely used.   Rather, Exceptions are desirable (at least in part) ecause they enable a style of coding  that can robustly handle corner cases with minimal complexity in the source code.   The alternative in Fortran is to (1)  have nearly all procedures and functions return an extra argument that is passed up the chain and (2) put a verbose check after each procedure and function to see if it returned cleanly.    I?m currently working with a ~3 million line code where this has been done quite consistently.     It is tedious and ugly.    In a few places they have used macros to hide the complexity. but that is in some ways worse.

> Or what about a demand to keep up
> with evolving hardware - GPU, KNL, etc.
> Is this a use case?

Again, that won?t resonate with most members of the committee.   HW changes faster than the standard could ever keep up with.          Come up with a use case that is problematic today (difficult to code or can?t get critical performance).    Possibly the committee can then design a feature that at least partially resolves the issue while having some lasting value.    

> A greater role to compiler engineers -
> might shift the balance of power
> more towards vendors.  While this is a legitimate
> point of view, indeed one might argue
> that only those who have to implement
> the standard should decide what's in it,
> it is only one view.

Egads no!    I might argue that only the implementors can vote on how _hard_ a feature would be to implement.    But the language is for the _users_, and their needs and priorities should be central to the discussion.    The vendors role/goal is to provide value to those users.


- Tom

> Anybody who's followed comp.lang.fortran
> lately would have seen the level of interest
> from Fortran users in what they deem
> the "missing" features.
> Talking about comp.lang.fortran, which
> apart from vendor specific groups and lists
> seems to be the most active Fortran
> discussion platform, is it in WG5 interest
> to engage more directly with CLF?

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

More information about the J3 mailing list