From owner-sc22wg5@open-std.org Mon Jan 12 15:19:35 2009 Return-Path: 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 ; 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 User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: ISO Fortran 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