From owner-sc22wg5@dkuug.dk Wed Jun 25 20:51:44 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5PIpipU060998 for sc22wg5-domo; Wed, 25 Jun 2003 20:51:44 +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 h5PIpXEc060993 for ; Wed, 25 Jun 2003 20:51:39 +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.3/gw-1.14) with ESMTP id h5PIpL9D022387; Wed, 25 Jun 2003 13:51:22 -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 h5PIpJwo026729; Wed, 25 Jun 2003 13:51:19 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-20-91 [172.31.20.91]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id NAA55554; Wed, 25 Jun 2003 13:51:19 -0500 (CDT) Message-ID: <3EF9F0C7.3070709@cray.com> Date: Wed, 25 Jun 2003 13:58:15 -0500 From: Bill Long 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 CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2810) Directions for Modules TR - levels References: <200306250003.h5P02dM5024710@math.jpl.nasa.gov> Content-Type: multipart/alternative; boundary="------------030701000705080303090007" X-Cray-VirusStatus: clean Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --------------030701000705080303090007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van Snyder wrote: >> >> > >For a large module there may be a need to share entities between >procedures in different submodules. With only two levels, the only place >to put those shared entities is in the module. This is really part of >the implementation. Putting it into the module could cause a >compilation/certification cascade as a consequence of changing an >implementation detail. So you need at least three levels. Once you have >three, there's really no point to a limit, although I doubt in practice >we would see more than three. > > I had thought about the issue of sharing things among a group of submodules. This seems like something that would be desirable. However, I don't agree that the only way to do this is with another layer of submodules. The shared stuff can be put in an ordinary module (not the parent) that is used by all the submodules in the group. This would seem to me the natural thing to do, having used modules in this way for a long time. The module with the shared stuff is not a submodule, eliminating the need for a third level, and is also unrelated to the parent module, so does not affect the key feature of avoiding compilation cascades. Is there a flaw in this approach? If not, it seems that the simplification that results from just two levels is desirable. 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 --------------030701000705080303090007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van Snyder wrote:

    


For a large module there may be a need to share entities between
procedures in different submodules.  With only two levels, the only place
to put those shared entities is in the module.  This is really part of
the implementation.  Putting it into the module could cause a
compilation/certification cascade as a consequence of changing an
implementation detail.  So you need at least three levels. Once you have
three, there's really no point to a limit, although I doubt in practice
we would see more than three.

I had thought about the issue of sharing things among a group of submodules. This seems like something that would be desirable. However, I don't agree that the only way to do this is with another layer of submodules. The shared stuff can be put in an ordinary module (not the parent) that is used by all the submodules in the group. This would seem to me the natural thing to do, having used modules in this way for a long time. The module with the shared stuff is not a submodule, eliminating the need for a third level, and is also unrelated to the parent module, so does not affect the key feature of avoiding compilation cascades. Is there a flaw in this approach? If not, it seems that the simplification that results from just two levels is desirable.

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

--------------030701000705080303090007--