From owner-sc22wg5@dkuug.dk Tue Aug 5 21:59:59 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h75JxxIc010226 for sc22wg5-domo; Tue, 5 Aug 2003 21:59:59 +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 mx1.liv.ac.uk (mx1.liv.ac.uk [138.253.100.179]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h75JxqEc010220 for ; Tue, 5 Aug 2003 21:59:54 +0200 (CEST) (envelope-from j.l.schonfelder@liverpool.ac.uk) Received: from mailhub5.liv.ac.uk ([138.253.100.157]) by mx1.liv.ac.uk with esmtp (Exim 4.14) id 19k7yE-0002e9-It for SC22WG5@dkuug.dk; Tue, 05 Aug 2003 20:59:46 +0100 Received: from localhost ([127.0.0.1] helo=mailhub5.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19k7yE-0007jG-Gz for SC22WG5@dkuug.dk; Tue, 05 Aug 2003 20:59:46 +0100 Received: from vp135022.liv.ac.uk ([138.253.135.22] helo=jls-rm-home.liv.ac.uk) by mailhub5.liv.ac.uk with esmtp (Exim 4.14) id 19k7yE-0007jD-AS for SC22WG5@dkuug.dk; Tue, 05 Aug 2003 20:59:46 +0100 Date: Tue, 05 Aug 2003 20:59:38 +0100 From: "J.L.Schonfelder" To: "SC22/WG5 members" Subject: N1572 Message-ID: <21331142.1060117178@jls-rm-home.liv.ac.uk> Originator-Info: login-id=jls; server=pop1.liv.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *19k7yE-0002e9-It*W92OoXdq73U* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk I have not yet checked Malcolm's proposed edits but I think I should comment on his preamble. To mix a few metaphors knocking down strawmen is not really cricket. The argument for not continuing to try to codify the permitting the non-redeclaration of the interface in the procedure implementation was not only because the description was difficult. The main reason was that in the event of nonredeclaration some rather nasty possibilities arose that would require even more disruption to the normal rules of host association than the subgroup thought reasonable or desirable. As I had to leave the meeting early I had not seen N1572 until ten minutes ago. The subgroup was especially concerned that with normal host association rules and no redeclaration the following was possible, within an separate procedure implementation that did not redeclare the interface it would be possible for a local variable of the same name as a dummy argument to be declared with obvious undesirable results. Subgroup thought about text that would prohibit such an undesirable accident but had not found a satisfactory set of rules (As an aside it was precisely this sort of problem that was a factor in my proposing submodule association instead of host association). We came to the conclusion that since redeclaration would be more useful and safer in practice we could best solve the problem at this time by making full interface redeclaration required. If Malcolm's suggested changes to the TR solve this problem and other associated issues then I would be happy to support the changes but I will need time to think carefully about the implications. I reluctantly acquiesced in the decision to go with host association as the relationship of submodule with parent because a number of practical problems were pointed out with submodule association as I had defined it. Nevertheless vanilla host association still has a significant set of practical infelicities some of which I have illustrated previously. Some of these are also mitigated by not allowing nonredeclaration of the implementation interface. I would not be happy to see these reintroduced by attempting to support "lazy programming". -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986