From owner-sc22wg5@dkuug.dk  Tue Sep 16 20:13:11 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.12.8p1/8.9.2) id h8GIDBlL068847
	for sc22wg5-domo; Tue, 16 Sep 2003 20:13:11 +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 h8GIBfCp068840
	for <sc22wg5@dkuug.dk>; Tue, 16 Sep 2003 20:13:08 +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 h8GIBmnT031489
	for <sc22wg5@dkuug.dk>; Tue, 16 Sep 2003 11:11:48 -0700
Received: from math.jpl.nasa.gov (vsnyder@localhost)
	by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h8GIBmpa031485
	for <sc22wg5@dkuug.dk>; Tue, 16 Sep 2003 11:11:48 -0700
Message-Id: <200309161811.h8GIBmpa031485@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: More on submodule name classification
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 16 Sep 2003 11:11:48 -0700
Sender: owner-sc22wg5@dkuug.dk
Precedence: bulk


In addition to the proposal at J3 meeting 165 that a submodule name ought
to be local to its ancestor module, instead of global, there was a proposal
that a submodule name ought to be local to its parent.

This was rejected as unnecessary and undesirable.  The hierarchy of
submodules of a module is not expected to be large, so extra subdivision
is not necessary.  It would also require explicit qualification of the
entire genealogy of a submodule name.  That is, submodule A of submodule B
of ... of module Z would be named something like Z%Y%X%...%B%A.  Indeed,
the conscious decision to use "<module-name>:<submodule-name>" to denote
the parent if it is a submodule was taken precisely because the colon
already functions in Fortran as an interval constructor.

Many, indeed most, Fortran processors use the host system's filing system
as a database for module information, rather than constructing a separate
one.  The ability to do so depends upon the ability to represent the entire
module name, and usually a few more characters (e.g. ".mod"), as a file name.
With only two levels of qualification, it is still likely to be possible to
use file names rather than a separate database.  One will bneed to be able to
represent two Fortran identifiers, plus a separator, plus maybe a few other
characters (e.g. "module:submodule.mod").  With unlimited qualification (well,
limited by Fortran's statement length), there is the distinct possibility that
most filing systems would run into a name-length limit for files before
running into Fortran's statement length limit.  This would require processors
to have a database of their own to represent module information.

-- 
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.