From owner-sc22wg5@dkuug.dk Tue Jul 8 21:03:04 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h68J343o046857 for sc22wg5-domo; Tue, 8 Jul 2003 21:03: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 math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h68J2uEc046852 for ; Tue, 8 Jul 2003 21:03:00 +0200 (CEST) (envelope-from vsnyder@math.jpl.nasa.gov) Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1]) by math.jpl.nasa.gov (8.12.8/8.12.8) with ESMTP id h68J2pJh001230 for ; Tue, 8 Jul 2003 12:02:51 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h68J2pOc001226 for ; Tue, 8 Jul 2003 12:02:51 -0700 Message-Id: <200307081902.h68J2pOc001226@math.jpl.nasa.gov> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Reply-to: Van.Snyder@jpl.nasa.gov From: Van.Snyder@jpl.nasa.gov To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2854) Straw votes to ponder concerning Modules TR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Jul 2003 12:02:51 -0700 Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Bill Long wrote: > Procedures defined in a submodule have the characteristics of external > procedures (i.e. no name mangling). This prevents procedures in different submodules, not necessarily submodules of the same module, from having the same name. One of the benefits of modules for developing really large programs is that one needn't worry about duplicating module procedure names in different modules. Module procedure names should depend on the program unit where their interface is declared -- where the interface body is if it's a separate procedure, and where the procedure body is otherwise. It would be much easier to migrate Fortran 77 external procedures to module procedures if the SUBROUTINE on the END statement were optional in a module. That way, one could write a module with a CONTAINS and a bunch of INCLUDE lines. If one wanted both external and module procedures, one could simply compile the include files, which would remain as self-contained program unit texts. > Should a submodule be allowed as a parent of another submodule? > I vote NO on this. I think that allowing multiple layers of submodules > is a gratuitous complication that serves no real purpose. If we put something in the interface body to indicate where the procedure body is, we definitely need to have more than two levels of submodule elaboration. Otherwise, if one rearranges the assignment of procedures to submodules, a change in the module is necessary, which could trigger a compilation/certification cascade. -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.