From owner-sc22wg5@dkuug.dk Fri Jun 20 15:59:33 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5KDxX40028584 for sc22wg5-domo; Fri, 20 Jun 2003 15:59:33 +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 h5KDxPEc028579 for ; Fri, 20 Jun 2003 15:59:29 +0200 (CEST) (envelope-from adonev@Princeton.EDU) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by Princeton.EDU (8.12.9/8.12.9) with ESMTP id h5KDxNar006011 for ; Fri, 20 Jun 2003 09:59:23 -0400 (EDT) Received: from princeton.edu (atom.Princeton.EDU [128.112.143.9]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id h5KDxM0k029976 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 20 Jun 2003 09:59:23 -0400 (EDT) Message-ID: <3EF3133A.5010402@princeton.edu> Date: Fri, 20 Jun 2003 09:59:22 -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.2794) Modules TR References: <200306191806.h5JI6COe022489@dkuug.dk> <200306201126.h5KBQV44027592@dkuug.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Hello, My thoughts on how to handle FORWARD interfaces. JLS wrote: > I could live with this but I would still want to add the qualifier for > the interface to the interface body and not the interface block. Again, I am not going to argue against the clear fact that the SEPARATE or FORWARD belongs logically to the interface body. But the same argument applies verbatim to ABSTRACT, yet we do have ABSTRACT INTERFACE and not ABSTRACT FUNCTION. At some point it was decided that the interface body should be the same as a regular FUNCTION/SUBROUTINE statement and so ABSTRACT was put on the block. I believe strongly in syntax consistency (otherwise it becomes impossible to improve it later and also to learn it!). I also seriously dislike the fact that FORWARD interfaces inherit the host environment by host association, unlike ordinary interfaces. This is inconsistent with existing rules and hard to learn. What does this mean about IMPORT in such an interface block? Can it appear and it simply means nothing? These questions will undoubtly pop up. I prefer to keep the rules consistent, even if this means keeping the (big mistake) F95 rules for interface blocks. At the risk of ranting and drumming my drum again, I would say that the "best" solution is to allow "merging" of generic blocks. Something like: FORWARD INTERFACE Separate_Procs REAL FUNCTION .... END FUNCTION INTEGER FUNCTION .. END FUNCTION END INTERFACE INTERFACE Generic GENERIC Separate_Procs LOGICAL FUNCTION .... END FUNCTION END INTERFACE I have advocated this several times with J3 for other reasons--it is quite a useful thing when designing large generics (write the integer ones first and bind them into a generic, then the reals, then merge the two, etc.). But it seems to be deemed a big change. Anyway, I find this much better then introducing all kinds of novel rules and concepts just to get the simple idea of submodules in the standard... >> REAL, DIMENSION(n*n) :: a ! Here n=5 > > The exact dependence on the named entities in the specification > expressions involved in declaring dummy arguments etc. are > characteristics of the procedure as I read the standard so the > accidental equivalence in value of n*n and m would not make the > characteristics identical. I believe this applies to cases where n is itself a dummy argument. If it is a parameter then only the final value matters (at least it should be this way). I am likely wrong though... Best, Aleksandar