From owner-sc22wg5@dkuug.dk  Wed Jun 18 19:59:29 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.12.8p1/8.9.2) id h5IHxTLr015911
	for sc22wg5-domo; Wed, 18 Jun 2003 19:59:29 +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 h5IHxJEc015906
	for <sc22wg5@dkuug.dk>; Wed, 18 Jun 2003 19:59:24 +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 h5IHxFJe004785;
	Wed, 18 Jun 2003 10:59:15 -0700
Received: from math.jpl.nasa.gov (vsnyder@localhost)
	by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h5IHxEnk004781;
	Wed, 18 Jun 2003 10:59:14 -0700
Message-Id: <200306181759.h5IHxEnk004781@math.jpl.nasa.gov>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
To: "J.L.Schonfelder" <j.l.schonfelder@liverpool.ac.uk>
cc: sc22wg5@dkuug.dk
Reply-to: Van.Snyder@jpl.nasa.gov
Subject: Re: (SC22WG5.2773) Modules TR 
In-Reply-To: Your message of "Wed, 18 Jun 2003 10:37:05 BST."
             <200306180937.h5I9beL8013363@dkuug.dk> 
From: Van.Snyder@jpl.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain
Date: Wed, 18 Jun 2003 10:59:14 -0700
Sender: owner-sc22wg5@dkuug.dk
Precedence: bulk


Lawrie:

Under the provisions of 02-123, your example wouldn't compile.  The
interface and implementation have to have the same characteristics. 
Types are not equivalent according to the text of their names.  For
nonsequence types, two objects have the same type if their declarations
refer to the same type definition, which is not the case in your
example.  The rules for sequence types are structural, and such that your
example still wouldn't compile.

I agree that host association is not perfect this purpose, but the
problems are not as dire as you paint them.

> MODULE DAD
> TYPE modstruct
>  REAL::a(10)
> ENDTYPE modstuct
> 
> FORWARD INTERFACE
>  FUNCTION modfun(x)
>   type(modstruct)::x
>   REAL::modfun
>  ENDFUNCTION modfun
> ENDINTERFACE
> ENDMODULE DAD
> 
> SUBMODULE (DAD) SON
> TYPE modstruct       ! under host association rules this declaration is permitted
>   CHARACTER::ch      ! and it creates a new type called modstruct local to the
> ENDTYPE modstruct    ! submodule and makes the module declared type inaccessible
> INTEGER:: n
> 
> IMPLEMENTATION modfun
>  FUNCTION modfun(x)
>   type(modstruct)::x

The argument X does not have the same type here as in the interface
declaration, so this violates the provisions of 02-123.

>   REAL::modfun
>   !........
>   n=<some-expression>
>   !........
>  ENDFUNCTION modfun
> ENDIMPLEMENTATION modfun
> ENDSUBMODULE SON