From owner-sc22wg5@dkuug.dk  Tue Jul 15 16:42:07 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.12.8p1/8.9.2) id h6FEg7Dq095684
	for sc22wg5-domo; Tue, 15 Jul 2003 16:42:07 +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 mx1.liv.ac.uk (mx1.liv.ac.uk [138.253.100.179])
	by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h6FEg1Ec095678
	for <sc22wg5@dkuug.dk>; Tue, 15 Jul 2003 16:42:03 +0200 (CEST)
	(envelope-from j.l.schonfelder@liverpool.ac.uk)
Received: from mailhub3.liv.ac.uk ([138.253.100.83])
	by mx1.liv.ac.uk with esmtp (Exim 4.14)
	id 19cR08-00076A-K2
	for sc22wg5@dkuug.dk; Tue, 15 Jul 2003 15:41:56 +0100
Received: from localhost.localdomain ([127.0.0.1] helo=mailhub3.liv.ac.uk)
	by mailhub3.liv.ac.uk with esmtp (Exim 4.14)
	id 19cR08-0006yF-HS
	for sc22wg5@dkuug.dk; Tue, 15 Jul 2003 15:41:56 +0100
Received: from vp135020.liv.ac.uk ([138.253.135.20] helo=jls-rm-home.liv.ac.uk)
	by mailhub3.liv.ac.uk with esmtp (Exim 4.14)
	id 19cR08-0006yC-8j
	for sc22wg5@dkuug.dk; Tue, 15 Jul 2003 15:41:56 +0100
Date: Tue, 15 Jul 2003 15:41:56 +0100
From: "J.L.Schonfelder" <j.l.schonfelder@liverpool.ac.uk>
To: sc22wg5@dkuug.dk
Subject: Re: (SC22WG5.2872) Consequences of current design of Modules TR
Message-ID: <13385737.1058283716@jls-rm-home.liv.ac.uk>
In-Reply-To: <200307112222.h6BMMQTb069726@dkuug.dk>
References:  <200307112222.h6BMMQTb069726@dkuug.dk>
Originator-Info: login-id=jls; server=pop1.liv.ac.uk
X-Mailer: Mulberry/2.2.1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *19cR08-00076A-K2*jAU7ZzUBHpk*
Sender: owner-sc22wg5@dkuug.dk
Precedence: bulk



--On 11 July 2003 11:23 -0700 Van.Snyder@jpl.nasa.gov wrote:

>
> The current draft of the Modules TR specifies that a submodule accesses
> its parent module or submodule by host association.  There are some
> "interesting" consequences of this.  These are all obvious once you
> think them through, but I want you to be aware of them before you try
> to choose whether a child submodule ought to access its parent by host
> association or the new form that Lawrie proposes.
>
> Suppose you have a module M with a child submodule C and a grandchild G.
>
> Suppose in M you declare a separate interface for a module procedure P.
> Suppose in C you declare another separate interface for a module
> procedure P. Suppose in G you define a separate module procedure P.
>
> The procedure P in G is related to the interface in C, not the one in M.
> This is the way host association works, and the TR does not propose to
> change it.  If another module accesses the interface for P from M, it
> can't invoke P or use it for a target or actual argument, because there's
> no corresponding procedure.  Hopefully, your linker will gripe.  Remember,
> the name for P that the linker sees is almost surely not P (or p or p_).
> It should be mangled with C (not M!) because that's where it's interface
> is declared.  But C is not accessible by use association.  Any scoping
> unit that does "use M, only: P" is going to get a P mangled with M.
>
> Now suppose M has another child submodule C2, and you define a separate
> module procedure P there.  Then that P's name would be mangled with
> M (not C2!), and "use M, only P" would access that P.
>
> Now suppose C has another submodule G2, in which there is a reference to
> P. This refers to the P mangled with C, which body is in G, not the P
> mangled with M, which body is in C2.
>
> This may be exactly what you want to happen, but you need to be aware of
> it, and use it carefully.  It's no different from an internal procedure
> having an interface body for a dummy procedure that's the same name as an
> interface body for an external procedure declared in its host procedure.
>
> Start over.
>
> Suppose in M you declare a separate interface for a module procedure P.
> Suppose in C you declare an interface for an external procedure, also
> named P. Suppose in G you define a separate module procedure P.
>
> The definition of P in G is illegal.  It cannot access a separate
> interface declaration of the same name by host association.  The
> interface of the same name that it accesses by host association is not a
> separate interface.
>
> This is the way host association works.  We all know how host association
> works.  None of this should be a surprise, once you think it through.
True, but this is so convolluted and unlike internal procedures where there 
is a proper containing scope that is accessible source code a submodule is 
an entirely separate body of code. This will make accidental redeclartion 
more probable and since it may unexpectedly produce wrong but legal code it 
could cause complex bugs in big programs.
>
> If we adopt Lawrie's proposal for a new kind of association, and allow to
> redeclare anything that's accessed from a parent by that kind of
> association, we should require procedure interfaces to have identical
> characteristics and identical dummy argument names.  Otherwise, you could
> get the kind of strangeness noticed by Michael Ingrassia yesterday (or
> was it Wednesday?).
My proposal was to define most of this complication away. Any redeclaration 
must by definition be of the parent submodule assocatied entity and all its 
properties, characteristics, names, definition status and values (if any) 
must merely confirm those inherited from the parent. The above Baroque 
possibilities do not exist. An entity be it a type, parameter, variable, 
procedure etc. declared in a parent is known by the same name and has the 
same interpretation down the whole of a descendant tree regardless how 
often it is redeclared.
Accidental redclaration is unlikely to result in legal code and if it did 
it would alsmost certainly be beniegn
>
> --
> 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.
>
>



--
Lawrie Schonfelder
Honorary Senior Fellow
University of Liverpool
1 Marine Park, West Kirby,
Wirral, UK, CH48 5HN
Phone: +44 (151) 625 6986 
