From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Sep 27 02:08:16 2017 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 333F8358676; Wed, 27 Sep 2017 02:08:16 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id A1BB4356D2C for ; Wed, 27 Sep 2017 02:08:12 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id v8R087Nr013478 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits) verified NO); Tue, 26 Sep 2017 17:08:08 -0700 Subject: Re: (j3.2006) (SC22WG5.5965) generic programming in F2020 From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: "Clune, Thomas L. (GSFC-6101)" Cc: fortran standards email list for J3 , WG5 In-Reply-To: <2F94D9EB-935B-4D68-A3B2-314DC05A68BD@nasa.gov> References: <20170926174021.A8F283587DC@www.open-std.org> <08474B91-8ACB-43E9-8568-8804C9FE3C44@cray.com> <20170926223420.27B2E3587DE@www.open-std.org> <20170926224445.C756D3587F5@www.open-std.org> <2F94D9EB-935B-4D68-A3B2-314DC05A68BD@nasa.gov> Content-Type: text/plain; charset="UTF-8" Organization: Yes Date: Tue, 26 Sep 2017 17:08:07 -0700 Message-ID: <1506470887.32527.146.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-37.el6) Content-Transfer-Encoding: 8bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Tue, 2017-09-26 at 23:42 +0000, Clune, Thomas L. (GSFC-6101) wrote: > I hate to be the downer on this thread, which I otherwise find fascinating, but … > > There is far too much discussion of solutions (or potential solutions) > and far too little on motivating concrete _use cases_. With use > cases in hand, we should be able to say “Approach X will not work for > use case Y, because …” or at least have lively debates about the > relative efficacy of differing approaches. I’ll try my best to > scrounge some time this weekend to put some real text behind a batter > of use cases that I have that dance around the issues of generic > programming and containers. > > I could easily offer some opinions on the statements made thus far, > but will refrain to follow my own advice. > > Cheers, > > - Tom For use cases for Ada generic packages or subprograms, which are the prototype for Fortran parameterized modules or subprograms, and have been around since 1983, look in any Ada textbook, e.g. by J. G. P. Barnes or Norman Cohen. The Ada 2012 Standard ISO/IEC 8652:2012 has examples. If anybody needs the PDF, I have it and can send it or post it somewhere, maybe in the Tutorials folder on the J3 server. There are even instructions for how GNAT compiles and instantiates them at https://www2.adacore.com/gap-static/GNAT_Book/html/node12.htm This is old technology that has been used for 34 years, and for which we don't need to invent new excuses to provide it. Insisting on inventing new use cases for such an obvious and old requirement that has already been satisfied by at least two other languages and widely used in both of them is just a way to justify sitting on our hands for another revision cycle. Fortran parameterized modules and subprograms are both useful. Any problem that can be solved by parameterized subprograms can be solved by parameterized modules, but not vice versa. If we only do one, it ought to be parameterized modules. Once again (third time today), a problem that parameterized modules can address but parameterized subprograms cannot is the disconnect between parameterized derived types and type-bound procedures that Richard Maine warned about in 1997.