From owner-sc22wg5@dkuug.dk Tue Jun 24 16:53:22 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5OErMEA053199 for sc22wg5-domo; Tue, 24 Jun 2003 16:53:22 +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 h5OEpVEc053186 for ; Tue, 24 Jun 2003 16:53:17 +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, 24 Jun 2003 07:48:43 -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, 24 Jun 2003 07:51:19 -0700 Received: by altair.dfrc.nasa.gov (Postfix, from userid 201) id BF8CF350AF; Tue, 24 Jun 2003 07:51:15 -0700 (PDT) From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16120.25955.630995.266227@altair.dfrc.nasa.gov> Date: Tue, 24 Jun 2003 07:51:15 -0700 To: sc22wg5@dkuug.dk Subject: (SC22WG5.2807) Directions for Modules TR In-Reply-To: <200306240017.h5O0HGFQ050176@dkuug.dk> References: <200306210245.h5L2jPSY021832@math.jpl.nasa.gov> <200306232343.h5NNhQR1049761@dkuug.dk> <200306240017.h5O0HGFQ050176@dkuug.dk> X-Mailer: VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Aleksandar Donev writes: > I clearly remember that at meeting 164 some wanted to be > able to put the body of the separate procedure in the *same* module. I, > like you, see no point in this and think it should not be allowed, but > cannot recall what arguments were put to the contrary. Did Bill say he saw no point in that? Well, perhaps. I might have missed it. Anyway, I think it should be allowed...or more pertinently I don't think it should be disallowed. The main reason is just that it seems an arbitrary restriction with no particular purpose or logic. Arbitrary restrictions are a complication and something for users to memorize and question. I don't think I'll bother trying to come up with scenarios where users migt want to do this - it seems pointless and I think the burden of proof is the other way. It should need to be demonstrated why we would go out of our way to disallow this. If it is just because someone thinks that the words we choose might be confusing in this case, then I don't think that much of an argument. We might as well disallow the name function as the name of a subroutine because that would be confusing (much more so). Is there an ambiguity, and implementation difficulty, or any actual techical reason for such a disallowance? I don't recall any such being suggested. Don't just add arbitrary rules to force people to follow your style choices. Of course we always force people to follow some style choices by not adding alternatives into the standard. But I find a rather big difference between failing to add a feature that supports a style someone might like vs explicitly adding a rule to forbid it. -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain