From owner-sc22wg5@dkuug.dk  Tue Sep 16 19:42:50 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.12.8p1/8.9.2) id h8GHgo13068657
	for sc22wg5-domo; Tue, 16 Sep 2003 19:42:50 +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 h8GHfECp068625
	for <sc22wg5@dkuug.dk>; Tue, 16 Sep 2003 19:42:44 +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 h8GHfLnT031327;
	Tue, 16 Sep 2003 10:41:21 -0700
Received: from math.jpl.nasa.gov (vsnyder@localhost)
	by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h8GHfKvE031323;
	Tue, 16 Sep 2003 10:41:20 -0700
Message-Id: <200309161741.h8GHfKvE031323@math.jpl.nasa.gov>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: sc22wg5@dkuug.dk
cc: "J.L.Schonfelder" <j.l.schonfelder@liverpool.ac.uk>
Reply-to: Van.Snyder@jpl.nasa.gov
Subject: Re: (SC22WG5.2999) New papers 
From: Van.Snyder@jpl.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 16 Sep 2003 10:41:20 -0700
Sender: owner-sc22wg5@dkuug.dk
Precedence: bulk

Lawrie:

You're mistaken about the effect of making the submodule name local to
the module.  It is not proposed to put it into class 1.  It is proposed
to put it into a class (4) of its own, with a separate instance for each
module.  This is similar to the way type components are handled.  The
effect of this is that the only possible clash is with the name of another
submodule having the same ancestor module.  In particular, the submodule
name ***will not*** clash with any local name in the submodule or any of
its descendants.

As of 03-199r1, a submodule name could clash with any other global name,
or a local name in the submodule (and maybe in any of its descendants -- I
haven't worked that one out for sure).  So the proposal in N1576 does
indeed reduce the possibility for name clashes.

In the syntax, it would only be necessary to mention both the parent and
the ancestor module only in the case that the parent is a submodule.  In
that case, since the parent submodule name is local to its ancestor module,
it would be necessary to mention the ancestor module -- just as it is
necessary to mention an object of a type in order to access its components.
We anticipate that submodules of submodules will be useful, but rare, so
requiring the extra mention of the ancestor module in a rare situation
is a small price to pay for dividing the submodule names into disjoint
noninteracting classes.

The second change proposed at meeting 165, i.e. to allow submodules only to
be children of a module, but to access each other by USE association, was
rejected by subgroup and not even brought to a vote of plenary.  It is only
reported so that others who might be tempted to bring it up again will know
it has already been considered and rejected.

Best regards,
Van