From owner-sc22wg5@dkuug.dk Wed Jun 25 19:08:09 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5PH89Ye060535 for sc22wg5-domo; Wed, 25 Jun 2003 19:08:09 +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 inf.rl.ac.uk (nfs7.inf.rl.ac.uk [130.246.72.7]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5PH83Ec060529 for ; Wed, 25 Jun 2003 19:08:05 +0200 (CEST) (envelope-from j.k.reid@rl.ac.uk) Received: from numerical.cc.rl.ac.uk (numerical [130.246.8.23]) by inf.rl.ac.uk (8.11.6+Sun/8.8.8) with ESMTP id h5PH64D05727 for ; Wed, 25 Jun 2003 18:06:04 +0100 (BST) Received: from rl.ac.uk (jkr.cse.rl.ac.uk [130.246.9.202]) by numerical.cc.rl.ac.uk (8.8.8+Sun/8.8.8) with ESMTP id SAA28139 for ; Wed, 25 Jun 2003 18:16:54 +0100 (BST) Message-ID: <3EF9D81D.5010602@rl.ac.uk> Date: Wed, 25 Jun 2003 18:13:01 +0100 From: John Reid Reply-To: j.k.reid@rl.ac.uk Organization: Rutherford Appleton Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: WG5 Subject: Re: (SC22WG5.2813) Thanks to Bill... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk -------- Original Message -------- Date: Wed, 25 Jun 2003 11:51:44 -0500 From: Dick Hendrickson X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2813) Thanks to Bill... References: <200306210235.h5L2ZcVH034177@dkuug.dk> <200306251402.h5PE2u4Z059600@dkuug.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "J.L.Schonfelder" wrote: > > I am not overly keen on SEPARATE but I could live with it. I entirely agree > with its appearing as a prefix on the FUNCTION/SUBROUTINE statement > introducing either the interface declaration and the separate module > procedure definition. > My only disagreement is with host association as the association rule > applying between the disjoint scopes of a submodule and its parent. Van > says he is not convinced by my arguments against host association. I can > only reply that I am totally unconvinced that there are any arguments FOR > host association. I have seen no agrument pointing out any technical, > expressive or functional advantages for using this association rule apart > from the trivial one that it already exists. I thought one of the major motivations for sub-modules was to allow large modules to be split into smaller parts to make maintenance and development easier. Doesn't this make host association the only natural model? If I take a big module and split it up into parts, why would I want the parts to obey different rules from what they currently follow? For the same reason, I'd think allowing SEPARATE routines to be in the parent module should be allowed. It allows, but doesn't require, subprograms to be moved around in the module/submodule tree with minimum changes. Codes grow, and as they get enhanced we don't want to make it hard to move things around as needs or understanding of the code changes. Dick Hendrickson