From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Sep 27 01:01:57 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 9CF2F3587F5; Wed, 27 Sep 2017 01:01:57 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id C2673356D2C for ; Wed, 27 Sep 2017 01:01:55 +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 v8QN1qKS021461 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits) verified NO) for ; Tue, 26 Sep 2017 16:01:53 -0700 Subject: Re: (j3.2006) (SC22WG5.5962) generic programming in F2020 From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 In-Reply-To: References: <20170926174021.A8F283587DC@www.open-std.org> <08474B91-8ACB-43E9-8568-8804C9FE3C44@cray.com> <20170926223420.27B2E3587DE@www.open-std.org> Content-Type: text/plain; charset="UTF-8" Organization: Yes Date: Tue, 26 Sep 2017 16:01:52 -0700 Message-ID: <1506466912.32527.136.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 22:44 +0000, Bill Long wrote: > > On Sep 26, 2017, at 5:34 PM, Van Snyder wrote: > > After parameterized modules were dropped in favor of macros, I proposed > > parameterized procedures. > > I have concluded they're too simplistic to be worth the effort. > > It depends on what problem you are trying to solve. If the problem is > “we don’t have parameterized modules”, then I agree templates do not > solve that problem. If it is “I don’t what to write multiple versions > of the same code with different argument type/kind combinations” then > it does solve that problem. More explicitly, parameterized procedures without parameterized modules aren't worth the effort. If you have parameterized modules, you get parameterized procedures at the expense of more instances of the module. I agree that parameterized procedures are handy, even within non-parameterized modules. But if you're dreaming of solving real problems using parameterized procedures but excluding parameterized modules, well, you're dreaming. On their own, they're not worth the effort. One example (again): They don't solve the problem of the disconnect between parameterized derived types and type-bound procedures. > > If we had done parameterized modules in 2003, I doubt we would have done > > parameterized types, at least types parameterized by kind, and we > > I assume you are talking about parameterized DERIVED types. > Parameterized intrinsic types have been a big win for Fortran. Parameterized intrinsic types were in Fortran 90. I explicitly referred to Fortran 2003.