From owner-sc22wg5@open-std.org  Mon Jan 12 15:19:35 2009
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 05B8AC178DE; Mon, 12 Jan 2009 15:19:35 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from mailrelay1.lrz-muenchen.de (mailrelay1.lrz-muenchen.de [129.187.254.106])
	by www2.open-std.org (Postfix) with ESMTP id 771B6C178D9
	for <sc22wg5@open-std.org>; Mon, 12 Jan 2009 15:19:33 +0100 (CET)
Received: from [129.187.15.179] ([129.187.15.179] [129.187.15.179]) by mailout.lrz-muenchen.de with ESMTP; Mon, 12 Jan 2009 15:19:18 +0100
Message-Id: <496B5166.7020001@lrz.de>
Date: Mon, 12 Jan 2009 15:19:18 +0100
From: Reinhold Bader <Reinhold.Bader@lrz.de>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: ISO Fortran <sc22wg5@open-std.org>
Subject: 09-007/UTI 151
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

 Hello,

 I'm trying to understand the UTI 151 (since I was initially responsible for the
 new feature I guess I should before it is unceremoniously ripped out
 again ...). Here some comments:

(1) In fact, the term "indirect" is not explicitly defined for access to entities at all; it is
      used in the standard in the context of
     * procedure invocation,
     * object reference through a pointer
     * use reference of modules
     This may well be reason enough to either properly define it or choose a different
     wording for what the feature is intended for.
(2) However, I am not sure I understand that any ambiguities actually occur based on
      the bullet list in UTI 151. In my opinion, "all-encompassing" pretty much is what
      is intended by the rule since it refers to *use association* only. Any entities needed
      from the ancestor can be accessed by the much more liberal host association anyway.
      For example take the case of  Bullet 1: "Access via use then pointer association".
      An example that comes to mind is

       use mod_b
       use mod_p
       type (b) :: ob
       :
       p => a

       "p" a pointer in mod_p, "a" a target in mod_a, "b" an entity in mod_b
      If the above code is in a submodule of a module mod_a use-referenced by mod_b, the
      compiler should be able to verify that "a" is accessed by use association (if not private)
      and reject the code. The user then corrects
      use mod_b, only : b
      and all is fine. If I am misunderstanding the bullet list, can someone provide an example
      which demonstrates either an ambiguity or a situation which cannot be checked by the
      compiler?
 (3) Would a change along the lines of

       (*) A submodule shall not directly reference its ancestor module via a use statement.
       (**) A submodule shall not access any entity from its ancestor module via use association.

       (perhaps even formulated as constraints?) accommodate the Editor's concerns? It may
       be advisable to also extend Note 11.7 to read

       * It is possible for a submodule to indirectly reference its ancestor via a use statement,
         provided that constraint (**) is fulfilled by applying suitable access restrictions (cf. Note 11.8).
       * It is possible for submodules with different ancestor modules to reference each others’
         ancestor modules by use association.

      To avoid back-references, all stuff within the scope of this discussion should probably be
      shifted to Clause 11.2.3, just after para 2.

Regards
 Reinhold