From owner-sc22wg5@dkuug.dk Thu Jun 19 20:06:11 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5JI6BSa022478 for sc22wg5-domo; Thu, 19 Jun 2003 20:06:11 +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 Princeton.EDU (root@postoffice01.Princeton.EDU [128.112.129.75]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5JI5xEc022471 for ; Thu, 19 Jun 2003 20:06:07 +0200 (CEST) (envelope-from adonev@Princeton.EDU) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by Princeton.EDU (8.12.9/8.12.9) with ESMTP id h5JI5vqE001417 for ; Thu, 19 Jun 2003 14:05:57 -0400 (EDT) Received: from princeton.edu (atom.Princeton.EDU [128.112.143.9]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id h5JI5vNX007203 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 19 Jun 2003 14:05:57 -0400 (EDT) Message-ID: <3EF1FB84.4080902@princeton.edu> Date: Thu, 19 Jun 2003 14:05:56 -0400 From: Aleksandar Donev Organization: Princeton Materials Institute, Princeton University 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: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2776) Modules TR References: <200306180116.h5I1GmdL011630@dkuug.dk> <200306180937.h5I9beL8013363@dkuug.dk> <200306181511.h5IFBGIm014975@dkuug.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk J.L.Schonfelder wrote: "Let me give the argument for redeclaration for submodules." I am not arguing against redeclaration, I was merely thinking about consistency. There are other places where I would like to allow it. For example, I would want to specify the interface of all type-bound procedures in an ABSTRACT interface block, very close to where the type is declared, even if they are not deferred bindings. Right now we have: TYPE ... CONTAINS PROCEDURE :: binding=>some_proc ! Go find this proc to see its interface ENDTYPE so that it is not easy to first design the interface (which as you say is a hard organizational step), and then write the implementations. The submodule proposal can help with the example above because some_proc can be made to be a procedure whose interface is a FORWARD one, and then the implementation can be elsewhere. I did not hear any replies to my comment #2: Aleksandar Donev wrote: > the SEPARATE is not really a characteristic of the procedure (this is > still a procedure that is compiled and called like any other (comapre > this to PURE/ELEMENTAL, etc, which apply to the way the procedure is > called and used), but rather, SEPARATE applies to the relation between > this procedure and its host. Thus, like we have CONTAINS, it seemed > natural to have an equivalent construct which marks a piece of the > subroutines as being implementations. I personally would prefer: > > SUBMODULE(Parent_Module) :: Sub_Module > ... > IMPLEMENTS > ! Separate procedures > CONTAINS > ! Regular ones > END SUBMODULE > > or some variant thereof. After thinking more about this and Richard's comments about adding things to the FUNCTION/SUBROUTINE statement, I am more convinced that putting SEPARATE there is a bad idea. Just like we do not say MODULE FUNCTION or MODULE SUBROUTINE for module procedures, we should not say SEPARATE. And kudos to NAG for catching the mismatch in dummy argument shapes. But, what if the dummy of the FORWARD interface had: REAL, DIMENSION(n*n) :: a ! Here n=5 and the one in the implementation had dimension m, where m=25, or maybe even n, where n was redeclared to be 25? This will work, yet it is clearly a mess we do not want to introduce. As Lawrie said, don't make a knife when all we need is a spoon. Best, Aleksandar