From owner-sc22wg5@dkuug.dk Tue Jul 15 11:23:56 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6F9NuEP094014 for sc22wg5-domo; Tue, 15 Jul 2003 11:23:56 +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 h6F9NpEc094009 for ; Tue, 15 Jul 2003 11:23:52 +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 h6F9LcD12750 for ; Tue, 15 Jul 2003 10:21:38 +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 KAA02767 for ; Tue, 15 Jul 2003 10:32:44 +0100 (BST) Message-ID: <3F13C9BF.6060401@rl.ac.uk> Date: Tue, 15 Jul 2003 10:30:39 +0100 From: John Reid Reply-To: j.k.reid@rl.ac.uk Organization: Rutherford Appleton Laboratory 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: [Fwd: Re: (SC22WG5.2872) Consequences of current design of Modules TR] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@dkuug.dk Precedence: bulk -------- Original Message -------- Subject: Re: (SC22WG5.2872) Consequences of current design of Modules TR Date: Tue, 15 Jul 2003 10:27:05 +0100 (BST) From: Malcolm Cohen Van.Snyder@jpl.nasa.gov wrote: >The current draft of the Modules TR specifies that a submodule accesses >its parent module or submodule by host association. There are some >"interesting" consequences of this. These don't seem to be significantly different from the "consequences" we already have. >Suppose you have a module M with a child submodule C and a grandchild G. We already have an exactly analogous situation with module procedures containing internal procedures. (details omitted). >This is the way host association works, and the TR does not propose to >change it. Right. > If another module accesses the interface for P from M, it >can't invoke P or use it for a target or actual argument, because there's >no corresponding procedure. Hopefully, your linker will gripe. Remember, Whether the linker gripes or not, this is just an unresolved reference the same as if you'd done an external interface block for a never-defined external procedure, or forgotten to include the object file for a module, etc. (And when building sharable objects, with many linkers you don't get a "gripe" because there is no error until you actually try to reference it at runtime and it cannot find the entity in your dynamic library list). >This may be exactly what you want to happen, but you need to be aware of it, As you say, it is no different from any other application of host association. They way you describe it makes it sound more complicated, but it is just the usual "local declaration stops host association" rule. You even have similar effects in USE chains, though admittedly that requires explicit renaming or ONLY clauses (which makes mistakes a little less likely). >This is the way host association works. We all know how host association >works. None of this should be a surprise, once you think it through. I'd be surprised if it worked any differently, that's for sure! >If we adopt Lawrie's proposal for a new kind of association, and allow to >redeclare anything that's accessed from a parent by that kind of association, >we should require procedure interfaces to have identical characteristics >and identical dummy argument names. Otherwise, you could get the kind of >strangeness noticed by Michael Ingrassia yesterday (or was it Wednesday?). Irrespective of "adopting Lawrie's proposal", I think that the dummy argument names have to be the same. To do otherwise would be complexity that provides the potential for confusion but no useful functionality. In particular, there should be *NO DIFFERENCE* between omitting the heading stuff in a separate procedure definition, and in redundantly including it. (Being able to specify different dummy argument names makes including it not redundant at all.) Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)