From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Wed Sep 27 00:44:35 2017
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id 58DF73587F5; Wed, 27 Sep 2017 00:44:35 +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 81AB3356D2C
	for <sc22wg5@open-std.org>; Wed, 27 Sep 2017 00:44:33 +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 v8QMiU7c010252
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits) verified NO)
	for <sc22wg5@open-std.org>; Tue, 26 Sep 2017 15:44:31 -0700
Subject: Re: (j3.2006) (SC22WG5.5959) generic programming in F2020
From: Van Snyder <Van.Snyder@jpl.nasa.gov>
Reply-To: Van.Snyder@jpl.nasa.gov
To: WG5 <sc22wg5@open-std.org>
In-Reply-To: <etPan.59caceb4.6c145680.b1c@sourceryinstitute.org>
References: <20170926174021.A8F283587DC@www.open-std.org>
	 <20170926212625.B452F3587DC@www.open-std.org>
	 <20170926214203.B5FA33587DC@www.open-std.org>
	 <CEE449A3-AC61-4C6D-8DEF-65CE14821863@cray.com>
	 <etPan.59caceb4.6c145680.b1c@sourceryinstitute.org>
Content-Type: text/plain; charset="UTF-8"
Organization: Yes
Date: Tue, 26 Sep 2017 15:44:30 -0700
Message-ID: <1506465870.32527.128.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 15:03 -0700, Damian Rouson wrote:
> 
> 
> On September 26, 2017 at 2:49:18 PM, Bill Long (longb@cray.com) wrote:
> 
> > 
> > 
> > > Does “defined” include cases in which only an interface body is
> > provided in the MODULE such as below? 
> > 
> > No. An interface only is inadequate. A key feature of templates is
> > that the compiler has to be able to find them at compile time.
> > Something defined in a submodule is not findable until link time. An
> > interface only declares a procedure. The actual procedure definition
> > has to be in the module for this to work. 
> > 
> > 
> 
> I really like this proposal except for the above restriction.  A large
> project that benefits from the additional modularization and reduced
> compilation times that can be associated with submodules would lose
> those benefits for any generic procedures.  I suppose it’s not
> incredibly burdensome in the use case that most interests us on the
> OpenCoarrays project, but I’d imagine a lot of users who have started
> down the path of using submodules on large projects might balk at
> being forced to eliminate them for any generic procedures.

As I remarked in an earlier message, we should look at Ada generic
packages.  The package definition and package body can be separate for a
generic package.  A submodule is (intentionally) similar to a separate
package body.  Since the Ada standard and Ada compilers appear not to
have trouble with separate package definitions and package bodies, I
don't see a reason why the Fortran standard and processors would.

BTW, Ada does allow generic procedures and functions within generic or
non-generic packages.  Outwith a generic procedure or function, the name
applies to the generic.  Within, it applies to a specific instance,
which can be overloaded, and therefore cannot be used with "new" to
create a recursive specific instance.

> Damian
> _______________________________________________
> J3 mailing list
> J3@mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3


