From owner-sc22wg5@dkuug.dk Fri Jun 20 01:14:03 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5JNE3c4024102 for sc22wg5-domo; Fri, 20 Jun 2003 01:14:03 +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 h5JNDtEc024093 for ; Fri, 20 Jun 2003 01:13:59 +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 h5JNDoJe010041 for ; Thu, 19 Jun 2003 16:13:50 -0700 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id h5JNDoFB010037 for ; Thu, 19 Jun 2003 16:13:50 -0700 Message-Id: <200306192313.h5JNDoFB010037@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: sc22wg5@dkuug.dk Reply-to: Van.Snyder@jpl.nasa.gov Subject: Re: (SC22WG5.2790) Modules TR In-Reply-To: Your message of "Thu, 19 Jun 2003 15:45:06 PDT." <200306192246.h5JMkgoE023922@dkuug.dk> From: Van.Snyder@jpl.nasa.gov Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 19 Jun 2003 16:13:50 -0700 Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Aleksandar Donev writes: > > You are misunderstanding me Van. I understand that we need some way to > > distinguish these separate procedures from ordinary module procedures. > > If you look at what I proposed there was an IMPLEMENTS and a CONTAINS > > block in the module, clearly marked and separate. Is Bill the only one > > that likes this idea? and Richard Maine continues: > I think it sounds at least plasuble at first glance. Afraid I > haven't had time for much more than a first glance, so I've > stayed mostly out of it. Just letting you know that, no, Bill > isn't the only one who at least thinks the idea sounds plausible. I dislike this less than I dislike IMPLEMENTATION ... END IMPLEMENTATION brackets, but only if one is allowed to have several IMPLEMENTS and CONTAINS sections, in any order: I like to alphabetize my procedure definitions, to make them easy to find in even moderate-size modules. If there's only one of each allowed, and there's a fixed order, I dislike this very much. I dislike the IMPLEMENTATION ... END IMPLEMENTATION bracket because it's so verbose. I dislike an IMPLEMENTS section because the fact that one is dealing with an implementation, as opposed to a complete declaration + definition of a procedure, is (potentially) indicated at some distance. I dislike both of them because they introduce more new words and constructs than necessary. Either with IMPLEMENTATION ... END IMPLEMENTATION brackets or an IMPLEMENTS section, we still need to put something in the interface, and the word we put there certainly cannot be IMPLEMENTATION or IMPLEMENTS. The attraction of simply putting SEPARATE in the in both the interface body and the procedure header is that it's only one word, and it conveys the concept "the rest of what's described 'here' for both definitions of 'here'', is separate, i.e., somewhere else." If you have a diffent word from SEPARATE, and it could be put in the of a procedure header in both an interface body and a procedure implementation, that would go onto my list ahead of either an IMPLEMENTATION ... END IMPLEMENTATION bracket or an IMPLEMENTS section. Where it goes with respect to putting SEPARATE in the depends on the word. Notice that if we use host association for the relation between the scoping units of the parent and its descendant submodule -- and so far Lawrie has not convinced me not to -- we *need* to distinguish the implementation somehow, whether by a section, brackets, or a word in the . Otherwise it would mask the interface of the same name accessed by host association. This is the way that host association normally works, and the Modules TR does not propose to make an exception. So far, all of the objections to putting SEPARATE into the in a or in both an interface body and an implementation have been pretty fuzzy. Like "Lots of things in Fortran are separate." Well, lots of things are implements too -- shovels, forks, and plus operators. Each specific procedure in a generic is an implementation. We just have to be careful and consistent about our definitions of common-usage words. If the only objection to SEPARATE is that it's a common-usage word that could mean many things, well, that objection applies to nearly every Fortran keyword. -- 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.