From owner-sc22wg5@dkuug.dk Wed Jun 18 17:37:04 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5IFb4YK015130 for sc22wg5-domo; Wed, 18 Jun 2003 17:37:04 +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 h5IFZdEc015119 for ; Wed, 18 Jun 2003 17:36:59 +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; Wed, 18 Jun 2003 08:33:01 -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 ; Wed, 18 Jun 2003 08:35:32 -0700 Received: from altair.dfrc.nasa.gov (localhost.localdomain [127.0.0.1]) by altair.dfrc.nasa.gov (8.12.8/8.12.5) with ESMTP id h5IFZXnl002755 for ; Wed, 18 Jun 2003 08:35:33 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.12.8/8.12.8/Submit) id h5IFZXwS002751; Wed, 18 Jun 2003 08:35:33 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16112.34501.516529.402373@altair.dfrc.nasa.gov> Date: Wed, 18 Jun 2003 08:35:33 -0700 To: sc22wg5@dkuug.dk Subject: (SC22WG5.2776) Modules TR In-Reply-To: <200306181511.h5IFBGIm014975@dkuug.dk> References: <200306180116.h5I1GmdL011630@dkuug.dk> <200306180937.h5I9beL8013363@dkuug.dk> <200306181511.h5IFBGIm014975@dkuug.dk> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Aleksandar Donev writes: > 1. I agree that the prefix FORWARD (or whatever) should go before the > FUNCTION/SUBROUTINE statement, rather then INTERFACE. I cannot remember > why we voted otherwise in J3, but I think the reason was that it would > speed cut & paste or something silly like that. No, it wasn't just "cut & paste". Much more a matter that the syntax of function/subroutine statements is already pretty complicated ... enough so that we *USUALLY* manage to screw it up every time we make a change. I emphasize the "usually" because it is true. We don't just sometimes screw it up, we usually do. I lost track of the number of iterations we went through with BIND(C) on function/subroutine statements, but it was several (hope we finally have it ok). This would add something else to function/subroutine statements. And the addition comes with a bunch of conditions/interactions. I bet we'd get it wrong. I also bet that, once it gets actually correct, the resulting conditions would be hard to follow for the reader of the standard trying to figure out what syntaxes were used where. To me, anyway, that was a lot bigger argument than any one about cut&paste of code. Describing this as "speed cut & paste or something silly like that" trivializes it inappropriately in my opinion. Perhaps there is adequate reason to put it on the function/subroutine statement; I don't necessarily think that is an unaceptable choice, but the issues are bigger than this trivialization suggests. > These issues are important, but I hope they will not stand in the way of > getting the submodule TR out ASAP. Well....my guess is that trying to diddle function/subroutine statements has a high probability of delaying the TR because I think it has a high probability of needing multiple meetings to get out the bugs. That's probably the biggest reason that I am leary of it. I don't find your hope "something silly"; I agree with it. Argue too sucessfully for the one change and you might find it counterproductive to this goal. Of course, I could be wrong....but then I also might be right... -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain