From owner-sc22wg5@dkuug.dk Wed Jul 2 21:11:47 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h62JBljA007245 for sc22wg5-domo; Wed, 2 Jul 2003 21:11:47 +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 h62JBdEc007240 for ; Wed, 2 Jul 2003 21:11:43 +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 h62JBcJe007183 for ; Wed, 2 Jul 2003 12:11:38 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h62JBb7B007179 for ; Wed, 2 Jul 2003 12:11:37 -0700 Message-Id: <200307021911.h62JBb7B007179@math.jpl.nasa.gov> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Reply-to: Van.Snyder@jpl.nasa.gov From: Van.Snyder@jpl.nasa.gov To: sc22wg5@dkuug.dk Subject: From Aleksandar Donev, concerning the Modules TR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 2003 12:11:37 -0700 Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Hello, Van, please forward this to the wg5 list (change of e-mail temporary problem...) I am not sure if e-mail votes count, but here are mine: 1. > By what form of association should a submodule be related to its parent? Submodule association, as proposed by Lawrie. Any redeclaration of a constant, object, derived type, etc., matches that in the parent module and does not introduce new entities. 2. > Should it be optional, prohibited or required to redeclare the > characteristics of a module procedure that has separate interface in its > body? It should be optional to redeclare the characteristics. A single developer (read: me) may develop both in sync, in which case duplicate cut and paste is error-prone. Other teams may use different people for the two tasks, and they should be allowed to redeclare (choose their own (shorter) names for example). 3. > Should it be possible to put a separate procedure body in the same module > or submodule as its interface body? Yes. 4. > Should the interface body for a module procedure that has a separate body > automatically access its environment by host association? I have no preference at this point. 5. > What syntax should be used to indicate that a module procedure has a > separate interface body? My answer would depend on the outcome of question 2. If redeclaration is required (an acceptable (even if undersirable) choice by me), then there is nothing special about a separate procedure as compared to an ordinary procedure. Therefore adding yet another prefix is a bad idea (ELEMENTAL SEPARATE REAL RECURSIVE FUNCTION F(x)!?!), since it is not a characteristic of the procedure in the sense that it makes no difference to the compiler as to how the procedure is compiled or envoked. So it should not become part of the procedure body at all! I proposed an IMPLEMENTS section, analogous to the CONTAINS (only one per module please!) If redeclaration is optional, then SEPARATE makes sense when not declaring any other characterstics: SEPARATE PROCEDURE(name) since this procedure body will look very different from usual ones and so it at least makes sense to qualify with a tag attached to it (rather then around it). In such a case I am OK with Van's proposal, even though I still prefer IMPLEMENTS. I repeat, if redeclaration is required, SEPARATE is a silly idea! Simple, yes, but also bad! Simple is not always good, especially if there is no other argument supporting it... Best, Aleksandar -- NOTE change of primary e-mail to adonev@math.princeton.edu __________________________________ Aleksandar Donev Complex Materials Theory Group (http://cherrypit.princeton.edu/) Princeton Materials Institute & Program in Applied and Computational Mathematics @ Princeton University Address: 419 Bowen Hall, 70 Prospect Avenue Princeton University Princeton, NJ 08540-5211 E-mail: adonev@math.princeton.edu WWW: http://atom.princeton.edu/donev Phone: (609) 258-2775 Fax: (609) 258-1177 __________________________________