From owner-sc22wg5@dkuug.dk Tue Jul 15 11:05:48 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6F95mZh093922 for sc22wg5-domo; Tue, 15 Jul 2003 11:05: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 h6F95gEc093917 for ; Tue, 15 Jul 2003 11:05: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 h6F93TD12699 for ; Tue, 15 Jul 2003 10:03:29 +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 KAA02754 for ; Tue, 15 Jul 2003 10:14:35 +0100 (BST) Message-ID: <3F13C57F.3070102@rl.ac.uk> Date: Tue, 15 Jul 2003 10:12:31 +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: [Fwd: Re: (SC22WG5.2871) Separate interfaces for module procedures] 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.2871) Separate interfaces for module procedures Date: Tue, 15 Jul 2003 09:48:02 +0100 (BST) From: Malcolm Cohen To: sc22wg5@dkuug.dk CC: John Reid Van.Snyder@jpl.nasa.gov wrote: >The current draft also doesn't say anything about dummy argument names. >This also was done to be consistent with existing interface body / procedure >relations. It could be changed, but there's already been some resistance >to allowing separate interface bodies to be different from other ones, >for example by accessing their environment by host association. Should >we make separate interfaces more different the others, or more alike them? I think that this is a red herring. An interface body specifies not just the characteristics of a procedure but also: - its name - the names of its non-label dummy arguments ...and there are already various rules active on the names of the dummies, in particular for generic resolution. Requiring these "separate module" procedures to have rules does not in any way affect the original interface body, which continues to specify the name, the names of the dummy arguments, and the characteristics. Bill Long wrote: >facilities available with modules. By putting the actual procedure body >in a submodule, the name is not mangled and legacy codes can call the >procedure without requiring a USE statement. New codes can USE the Well, I had thought you were not serious. This simply does not hold water, and is contrary not only to the whole submodule philosophy, but also to the whole point of having them, viz to support large programs. What you are suggesting is not to put the name into the module namespace but into the global namespace. Completely at odds with modularisation principles! Think name clash. Think lack of checking for proper use of facilities (you no longer have compiler enforcement of "you cannot reference this procedure without an explicit interface"). If you just want a glorified external procedure (and not too glorified at that, since you propose being able to reference it without USEing the module), just use INCLUDE and be done with it. In a later message, Bill wrote (re Van's complicated description of simple host association): >I would just point out that all of this complexity is avoided it we >disallow grandchildren. No it's not. The complexity, so far as it exists, is called host association, and we have it in the language already. People even like it! Unless you want to have "no name mangling", I see virtually no additional complexity (over and above the submodule concept, and the duplicate declaration concept) imposed by the draft PDTR. And having "no name mangling" for the separate module procs effectively removes almost all use for the facility entirely, making it little more than syntactic cyanide for bog-standard interface blocks in a bog- standard module or INCLUDE file. At the implementation level, given name mangling, I see little complexity problem. For the separate module procedures, their linker name can be (and IMO ought to be) just the same as if they were ordinary module procedures ("mangled", as Van points out, by name of the module/submodule where they are declared (i.e. their interface body appears) not where they are defined (i.e. where their implementation appears). This appears to be completely straightforward to implement, indeed doing anything else would appear to be adding gratuitous complexity for no benefit. Allowing "grandchildren" (or indeed arbitrary "nesting") imposes little or no additional complexity that I have noticed. Indeed, imposing a "nesting" limit would itself require additional checking to be added to the compiler to detect and prevent invalid "nesting". Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk) ----- End of forwarded message (env-from malcolm) ----- -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)