From owner-sc22wg5@dkuug.dk Fri Jun 20 10:42:48 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5K8gmDk026489 for sc22wg5-domo; Fri, 20 Jun 2003 10:42:48 +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 h5K8ggEc026484 for ; Fri, 20 Jun 2003 10:42:44 +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 h5K8enD25902 for ; Fri, 20 Jun 2003 09:40:49 +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 JAA27358 for ; Fri, 20 Jun 2003 09:51:30 +0100 (BST) Message-ID: <3EF2CA0D.8000206@rl.ac.uk> Date: Fri, 20 Jun 2003 09:47:09 +0100 From: John Reid Reply-To: j.k.reid@rl.ac.uk 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.2787) Modules TR Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk -------- Original Message -------- To: Aleksandar Donev cc: sc22wg5@dkuug.dk, vsnyder@math.jpl.nasa.gov Subject: Re: (SC22WG5.2787) Modules TR In-Reply-To: Message from Aleksandar Donev of "Thu, 19 Jun 2003 14:05:56 EDT." <200306191806.h5JI6COe022489@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 19 Jun 2003 13:02:43 -0700 From: Van Snyder Aleksandar Donev 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. Indeed, under provisions of 03-123 ***that's what happens*** if you leave off the IMPLEMENTATION ... END IMPLEMENTATION brackets. RECURSIVE isn't a characteristic, but we put it into the ; we don't require RECURSIVE ... END RECURSIVE brackets around the procedure. > And kudos to NAG for catching the mismatch in dummy argument shapes. I agree. I should have checked the first page of Section 12 before writing. This eliminates another possibility that host association could cause an uncheckable bizarreness. I haven't seen an example of an uncheckable bizarreness that arises from host association -- but then, I didn't keep Lawrie's examples (so I can't check) because I assumed I could just look in the WG5 mail archive -- but now I can't find the WG5 mail archive. Is there any possibility, with host association, that something uncheckable could happen to the relation between a forward interface, and the corresponding fully-declared interface in the implementation? There is a possibility that naive users would be surprised: module M integer, parameter :: RK = kind(0.0d0) type T real(rk) :: C end type T ... end module M submodule(M) S integer, parameter :: RK = kind(0.0e0) ! overrides RK from M type(T) :: V ... end submodule S The component V%C has the kind of 0.0d0. The redeclaration of RK **DOES NOT** affect the definition of type T, or the way it is interpreted when it is used to declare a variable. This is already clear in the standard's discussion of host association, and nothing in the Modules TR would change that. I understand why Lawrie wants to redeclare things in submodules, but we don't allow this in the case of USE or host association, to which the same arguments that Lawrie is advancing could be applied. The only reason I proposed in early discussion of the separate Module/Submodule facility to require redefining the interface of a procedure in its implementation was because both Modula-2 and Ada require it. I don't have my Modula-2 and Ada references to hand, but if I remember correctly, there is a difference with Fortran: Modula-2 and Ada don't declare the dummy argument names in the interface; they just declare the types (which include dimensions) -- and Ada declares the intent. So they have to give at least the dummy argument names in their implementations. Wirth and Ichbiah opted to say everything. Lawrie's arguments haven't convinced me that we *need* to abandon host association and embrace a new form. Indeed, they haven't convinced me that there's any substantial benefit to be gained, that wouldn't be more than offset by a loss in another quarter. One might argue that allowing to redeclare the interface of a separate procedure in its body is inconsistent with host association. That is precisely why we distinguish the text of a separate procedure: So we'll *KNOW* it's not intended to mask the one accessed from the parent. We don't have any mechanism to distinguish the redeclaration of other entities from a declaration that masks one accessed by host association. If we were to adopt Lawrie's proposal for submodule association, we still wouldn't have a meachanism to distinguish them, but the tables would be turned. We may someday want to distinguish masking declarations from redeclarations, no matter which way we go concerning the association rules between a parent and descendant. For example, if we stick with host association, we could add a REDECLARATIONS ... END REDECLARATIONS block in the specification part of a program unit. Putting it just into the specification part of a submodule would make readers ask "Why can't I do this in an internal subroutine?" It is therefore so broad that it definitely falls outside the scope of the TR. If it's eventually found to be really really desirable it could be added compatibly at a later date. If we change to submodule association, we could add a block that says "the enclosed entities are new ones intended to mask the ones gotten from the parent as if the ones gotten from the parent were gotten by host association" but that wouldn't do a thing for those wanting to redeclare entities accessed by host association into different scopes, and wouldn't have application anywhere else: it would be a wart. Therefore I think the TR should continue to specify host association. Then, if we want to change things in the future, and be consistent throughout all scoping units, we would need only one change. This leaves us with a simple choice: Do we want to use host association, and forego (at least for now) the ability to redeclare entities other than procedure interfaces accessed from the parent, or do we want to invent a new form of association, and forego (at least for now) the ability to mask entities other than procedure interfaces accessed from the parent? -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.