From owner-sc22wg5@dkuug.dk  Wed Jul  9 00:16:47 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.12.8p1/8.9.2) id h68MGlGh047935
	for sc22wg5-domo; Wed, 9 Jul 2003 00:16:47 +0200 (CEST)
	(envelope-from owner-sc22wg5@dkuug.dk)
X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f
Received: from mail1.cray.com (mail1.cray.com [136.162.0.111])
	by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h68MGdEc047927
	for <sc22wg5@dkuug.dk>; Wed, 9 Jul 2003 00:16:42 +0200 (CEST)
	(envelope-from longb@cray.com)
Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110])
	by mail1.cray.com (8.12.9/8.12.9/gw-1.2) with ESMTP id h68MGV4G021440;
	Tue, 8 Jul 2003 17:16:32 -0500 (CDT)
Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14])
	by relayb.mw.cray.com (8.12.9/8.12.6/hub-1.2) with ESMTP id h68MGUF7021847;
	Tue, 8 Jul 2003 17:16:30 -0500 (CDT)
Received: from cray.com (cf-vpn-192-168-239-28 [192.168.239.28]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id RAA360627; Tue, 8 Jul 2003 17:16:25 -0500 (CDT)
Message-ID: <3F0B4465.9010008@cray.com>
Date: Tue, 08 Jul 2003 17:23:33 -0500
From: Bill Long <longb@cray.com>
Reply-To: longb@cray.com
Organization: Cray Inc.
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Van.Snyder@jpl.nasa.gov
CC: sc22wg5@dkuug.dk
Subject: Re: (SC22WG5.2856) Straw votes to ponder concerning Modules TR
References: <200307081903.h68J35Fg046868@dkuug.dk>
Content-Type: multipart/alternative;
 boundary="------------080102060201040901020007"
X-Cray-VirusStatus: clean
Sender: owner-sc22wg5@dkuug.dk
Precedence: bulk


--------------080102060201040901020007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Van.Snyder@jpl.nasa.gov wrote:

>Bill Long wrote:
>
>  
>
>>Procedures defined in a submodule have the characteristics of external 
>>procedures (i.e. no name mangling).
>>    
>>
>
>This prevents procedures in different submodules, not necessarily submodules
>of the same module, from having the same name.  One of the benefits of
>modules for developing really large programs is that one needn't worry
>about duplicating module procedure names in different modules.
>

Yes, that is the price paid for this particular simplification.  I 
expect people to have differing opinions on whether it is a good 
trade-off.  

>
>Module procedure names should depend on the program unit where their
>interface is declared -- where the interface body is if it's a separate
>procedure, and where the procedure body is otherwise.
>

Right.  The procedures in my version of submodules would not be module 
procedures in this sense.

>
>It would be much easier to migrate Fortran 77 external procedures to
>module procedures if the SUBROUTINE <name> on the END statement were
>optional in a module.  That way, one could write a module with a
>CONTAINS and a bunch of INCLUDE lines.  If one wanted both external and
>module procedures, one could simply compile the include files, which
>would remain as self-contained program unit texts.
>

There is another way (standard violating,  not portable, and not 
recommended by me) to accomplish this.  You can edit the 
subroutine/function statements to include a bind(c,name=....) clause, 
with the external name specified.  This way you end up with only one set 
of object code, rather than 2 with the include method.  As a quick and 
dirty workaround, this has been known to work.

>
>  
>
>>Should a submodule be allowed as a parent of another submodule?
>>    
>>
>
>  
>
>>I vote NO on this.  I think that allowing multiple layers of submodules 
>>is a gratuitous complication that serves no real purpose.
>>    
>>
>
>If we put something in the interface body to indicate where the procedure
>body is, we definitely need to have more than two levels of submodule
>elaboration.  Otherwise, if one rearranges the assignment of procedures
>to submodules, a change in the module is necessary, which could trigger
>a compilation/certification cascade.
>

True.  However, in my scheme there is no change to the interface body so 
this is not an issue.  In fact, I see this is a good argument against 
putting the procedure body location in the interface.


Cheers,
Bill

>
>  
>

-- 
Bill Long                                   longb@cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

            



--------------080102060201040901020007
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Van.Snyder@jpl.nasa.gov">Van.Snyder@jpl.nasa.gov</a> wrote:<br>
<blockquote type="cite" cite="mid200307081903.h68J35Fg046868@dkuug.dk">
  <pre wrap="">Bill Long wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Procedures defined in a submodule have the characteristics of external 
procedures (i.e. no name mangling).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This prevents procedures in different submodules, not necessarily submodules
of the same module, from having the same name.  One of the benefits of
modules for developing really large programs is that one needn't worry
about duplicating module procedure names in different modules.</pre>
</blockquote>
<br>
Yes, that is the price paid for this particular simplification. &nbsp;I expect
people to have differing opinions on whether it is a good trade-off. &nbsp;<br>
<br>
<blockquote type="cite" cite="mid200307081903.h68J35Fg046868@dkuug.dk">
  <pre wrap="">

Module procedure names should depend on the program unit where their
interface is declared -- where the interface body is if it's a separate
procedure, and where the procedure body is otherwise.</pre>
</blockquote>
<br>
Right. &nbsp;The procedures in my version of submodules would not be module procedures
in this sense.<br>
<br>
<blockquote type="cite" cite="mid200307081903.h68J35Fg046868@dkuug.dk">
  <pre wrap="">

It would be much easier to migrate Fortran 77 external procedures to
module procedures if the SUBROUTINE &lt;name&gt; on the END statement were
optional in a module.  That way, one could write a module with a
CONTAINS and a bunch of INCLUDE lines.  If one wanted both external and
module procedures, one could simply compile the include files, which
would remain as self-contained program unit texts.</pre>
</blockquote>
<br>
There is another way (standard violating,&nbsp; not portable, and not recommended
by me) to accomplish this. &nbsp;You can edit the subroutine/function statements
to include a bind(c,name=....) clause, with the external name specified.
&nbsp;This way you end up with only one set of object code, rather than 2 with
the include method. &nbsp;As a quick and dirty workaround, this has been known
to work.<br>
<br>
<blockquote type="cite" cite="mid200307081903.h68J35Fg046868@dkuug.dk">
  <pre wrap="">

  </pre>
  <blockquote type="cite">
    <pre wrap="">Should a submodule be allowed as a parent of another submodule?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">I vote NO on this.  I think that allowing multiple layers of submodules 
is a gratuitous complication that serves no real purpose.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
If we put something in the interface body to indicate where the procedure
body is, we definitely need to have more than two levels of submodule
elaboration.  Otherwise, if one rearranges the assignment of procedures
to submodules, a change in the module is necessary, which could trigger
a compilation/certification cascade.</pre>
</blockquote>
<br>
True. &nbsp;However, in my scheme there is no change to the interface body so
this is not an issue. &nbsp;In fact, I see this is a good argument against putting
the procedure body location in the interface. <br>
<br>
<br>
Cheers,<br>
Bill<br>
<br>
<blockquote type="cite" cite="mid200307081903.h68J35Fg046868@dkuug.dk">
  <pre wrap="">

  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
Bill Long                                   <a class="moz-txt-link-abbreviated" href="mailto:longb@cray.com">longb@cray.com</a>
Fortran Technical Support    &amp;              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

            
</pre>
<br>
</body>
</html>

--------------080102060201040901020007--