(j3.2006) HPCWire article (by Mike Heroux) discusses the advancement and future of Fortran

[Damian Rouson]

I liked the article a lot.  It was nice to see Fortran in the mix (which isn?t always the case in such articles) and great to see an influential person who I think shares my  viewpoint that the highest reasonable aim for a DSL is to influence an established language.  In this regard, I think it would be great for the committee at some point to consider what is the best mechanism for ?on-roading? (to coin a term) external contributions to the language.  Other languages have embedded DSLs, but I don?t know of any DSLs embedded in Fortran.  In C++, it appears the primary mechanism for an embedded DSL to influence the language are templates + namespaces.  As I understand it, Berkeley?s UPC++ and Cray's Coarray C++ are template libraries that the C++ committee could someday incorporate into the language by doing not much more than changing their respective namespaces to ?std?.  I imagine the closest thing we have to this capability is modules, but there are many useful language capabilities that can?t be fully reduced to implementing in a module.

Sadly, Mike?s strongest criticism of Fortran remains valid.  I expend a lot of energy in various forums arguing that the compilers support for Fortran 2003 and even 2008 is now sufficiently widespread that it?s no longer a valid reason to avoid updating codes.  I get a lot of pushback when I advocate for feature x, but someone retorts that it isn?t supported by compiler y, which they critically need for feature z.  The latest episode of this is in a new forum just launched this week that is currently discussing best practices.  Now that submodules are supported by the Cray, IBM, Intel, and GNU compilers (listed roughly in chronological order of the addition of submodule support), I advocate for widespread evaluation and use, but there is a significant community for whom CUDA Fortran is a requirement that ties them to Portland Group (sorry to name names ? there could be other examples with other compilers), which certainly can?t be ignored when the fastest computer in the country is filled with NVIDIA GPUs.

I don?t know what can be done about this problem and I think the committee is doing a lot already by holding the line on new features, but it really is the case that a significant percentage of the world is still writing Fortran 95 because there are ?only" four Fortran 2003 compilers and only one Fortran 2008 compiler. Without question, uneven compiler support for the standards is the number one complaint I hear universally about Fortran ? bar none.  But this also loops me back to my first paragraph above.  If there were a more obvious path for groups external to the committee and external to the commercial implementers to develop language extensions and propose them for incorporation into the language without first modifying a compiler (and thereby tying the new features to a particular compiler), then we?d probably be in a very different place regarding widespread testing and adoption of new features and shortened development cycles for implementers. Imagine if implementers could add a first draft of a new feature by doing not much more than adding a new namespace and bundling the associated source code. 
 
Regards,
Damian

> On Jan 15, 2016, at 8:15 AM, Bill Long <longb at cray.com> wrote:
> 
> I saw that, and have already started a list of replies to send to Mike personally.   Particularly annoying that he still uses the non-portable argument about coarrays after all the work the gfortran people did.   But, keep in mind that Mike is a leader in the C++ religion and is hardly unbiased on this topic.  No surprise that once C++ 2020 arrives all will be fabulous. 
> 
> His binding to C++ does lead him to argue that ?new? languages (i.e. not C, C++, Fortran) are unlikely to get traction.  On that score, I think he is likely to get wider agreement. 
> 
> Cheers,
> Bill
> 
> 
> On Jan 15, 2016, at 8:10 AM, Tom Clune <Thomas.L.Clune at nasa.gov> wrote:
> 
>> http://www.hpcwire.com/2016/01/14/24151/
>> 
>> 
>> 
>> Thomas Clune, Ph. D. 	<Thomas.L.Clune at nasa.gov>
>> Software Infrastructure Team Lead
>> Global Modeling and Assimilation Office, Code 610.1
>> NASA GSFC		
>> MS 610.1 B33-C128
>> Greenbelt, MD 20771
>> 301-286-4635
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> Bill Long                                                                       longb at cray.com
> Fortran Technical Support  &                                  voice:  651-605-9024
> Bioinformatics Software Development                     fax:  651-605-9142
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3