From owner-sc22wg5@dkuug.dk Thu Jun 19 23:06:03 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5JL63vN023510 for sc22wg5-domo; Thu, 19 Jun 2003 23:06:03 +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 h5JL5uEc023505 for ; Thu, 19 Jun 2003 23:05:59 +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 h5JL5sar019347 for ; Thu, 19 Jun 2003 17:05:54 -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 h5JL5r0k024143 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 19 Jun 2003 17:05:53 -0400 (EDT) Message-ID: <3EF225B1.7070001@princeton.edu> Date: Thu, 19 Jun 2003 17:05:53 -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.2787) Modules TR References: <200306192002.h5JK2hKK009030@math.jpl.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Van Snyder wrote: >>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. >> >> > >We don't say MODULE SUBROUTINE because it isn't necessary or useful. The >reason to say a procedure body is an implementation if we have host >association is that without saying so, it would be a new entity, masking >any entity of the same name accessed from the parent by host >association. > You are misunderstanding me Van. I understand that we need some way to distinguish these separate procedures from ordinary module procedures. If you look at what I proposed there was an IMPLEMENTS and a CONTAINS block in the module, clearly marked and separate. Is Bill the only one that likes this idea? >RECURSIVE isn't a characteristic, but we put it into the >; we don't require RECURSIVE ... END RECURSIVE brackets around >the procedure. > RECURSIVE is not a characteristic as far as the calling convention is concerned, which is why it was not put as a characterstic (this was way before my time). But it is an *internal* characteristic of the procedure, just like PURE, ELEMENTAL or BIND(C) or any other decoration is. SEPARATE on the other hand is a characterstic of the relation between the procedure and its enclosing host, and not of the procedure itself. It therefore does not belong on the FUNCTION/SUBROUTINE statement. We already have enough things that go there and another (possibly screwed up) addition is not a good idea IMO. As to the rest of the argument about redeclaration, I am retiring from it. It is obviously a straw-vote decision (unless someone brings out more convincing arguments for either side). Best, Aleksandar