From owner-sc22wg5@dkuug.dk Wed Jun 18 17:11:15 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5IFBFj0014963 for sc22wg5-domo; Wed, 18 Jun 2003 17:11:15 +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@postoffice02.Princeton.EDU [128.112.130.38]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5IFB8Ec014953 for ; Wed, 18 Jun 2003 17:11:11 +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 h5IFB2ar023844; Wed, 18 Jun 2003 11:11:04 -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 h5IFB0NX000880 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Jun 2003 11:11:02 -0400 (EDT) Message-ID: <3EF08103.9060304@princeton.edu> Date: Wed, 18 Jun 2003 11:10:59 -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 CC: "J.L.Schonfelder" , Van Snyder Subject: Re: (SC22WG5.2773) Modules TR References: <200306180116.h5I1GmdL011630@dkuug.dk> <200306180937.h5I9beL8013363@dkuug.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Hello, Since I am not coming to Dresden, my two cents, for those that care about what I think. I discuss 3 issues in turn: 1. I agree that the prefix FORWARD (or whatever) should go before the FUNCTION/SUBROUTINE statement, rather then INTERFACE. I cannot remember why we voted otherwise in J3, but I think the reason was that it would speed cut & paste or something silly like that. 2. The same cut & paste applied to the reason we chose to enclose the implementation of a procedure in an IMPLEMENTATION block, rather then just add a prefix SEPARATE before the FUNCTION/SUBROUTINE. One could just move a whole block of procedures into a submodule and add the IMPLEMENTATION around it. It also kind of tells that 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. 3. The redeclaration business seems to be the sticky issue. I am somewhat ambivalent about it. If I had to vote, I would support John's argument: We *do not* allow redeclation of entities anywhere else, even though there are places where I would have liked to allow it. But I agree that Lorrie's example is hidious when interpreted via host association...I would be happier to forbid redeclaration of anything but the interface...but do not feel strongly about it yet. What I do feel strongly about is the need to either *fully* respecify the inteface, or not specify it at all, as in: SEPARATE PROCEDURE(Name_Of_Procedure) though the syntax depends on how the IMPLEMENTation block syntax is chosen. I really dislike the ability to declare 1/4th of an interface and leave the rest to be inherited! These issues are important, but I hope they will not stand in the way of getting the submodule TR out ASAP. Thanks, Aleksandar (stuck in Princeton :-()