From owner-sc22wg5@dkuug.dk Tue Jul 29 18:03:58 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6TG3wSk059669 for sc22wg5-domo; Tue, 29 Jul 2003 18:03:58 +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 mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h6TG3nEc059663 for ; Tue, 29 Jul 2003 18:03:55 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for sc22wg5@dkuug.dk; Tue, 29 Jul 2003 09:00:50 -0700 Received: from altair.dfrc.nasa.gov ([130.134.20.211]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Tue, 29 Jul 2003 09:03:41 -0700 Received: by altair.dfrc.nasa.gov (Postfix, from userid 201) id 4AA14350AE; Tue, 29 Jul 2003 09:03:37 -0700 (PDT) From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16166.39641.208940.729397@altair.dfrc.nasa.gov> Date: Tue, 29 Jul 2003 09:03:37 -0700 To: WG5 Subject: (SC22WG5.2876) [Fwd: Separate interfaces for module procedures] In-Reply-To: <200307150905.h6F95nFM093933@dkuug.dk> References: <200307150905.h6F95nFM093933@dkuug.dk> X-Mailer: VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Malcolm writes: > 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,... I think I missed the original (perhaps in the flood of repeat messages from the server), so perhaps I am missing important context, but based on the above snippet, I echo Malcolm's (I think they were Malcolm's) comments. I'd interpret the suggestion above as tantamount to saying "let's not do anything like submodules at all; instead, let's do something that addresses completely different goals." And yes, it does remind me of external procedures. Heck, it brings to mind one place where I do use an external procedure in my f90 code to hack around what would otherwise be a serious compilation cascade. (For the server side of client/server apps, I want a different procedure for handling error messages so that they get to the client and to a log file - sending them to the standard output or standard error of the server process isn't very useful. But *EVERYTHING* depends on the module that has the error handling procedure, so without some hack I'd have to have separate client and server versions of everything instead of just a single separate procedure.) Yes, it appears to me to be different goals, not just different solutions. If we don't think that the modules TR is a good idea, then we can reject it. (Personally, I think the modules TR is a good idea). I do agree that we should consider alternative approaches to solving the problem, but this just doesn't sound to me like it is even talking about the same problem. Either I am majorly missing the point, or I vehemently disagree with it (or both). -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain