From owner-sc22wg5@dkuug.dk Tue Jul 15 13:41:37 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6FBfbpX094767 for sc22wg5-domo; Tue, 15 Jul 2003 13:41:37 +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 mx2.liv.ac.uk (mx2.liv.ac.uk [138.253.100.180]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h6FBfVEc094761 for ; Tue, 15 Jul 2003 13:41:32 +0200 (CEST) (envelope-from j.l.schonfelder@liverpool.ac.uk) Received: from mailhub3.liv.ac.uk ([138.253.100.83]) by mx2.liv.ac.uk with esmtp (Exim 4.14) id 19cOBR-0004UU-UQ for sc22wg5@dkuug.dk; Tue, 15 Jul 2003 12:41:25 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mailhub3.liv.ac.uk) by mailhub3.liv.ac.uk with esmtp (Exim 4.14) id 19cOBR-0004Vz-SU for sc22wg5@dkuug.dk; Tue, 15 Jul 2003 12:41:25 +0100 Received: from vp135020.liv.ac.uk ([138.253.135.20] helo=jls-rm-home.liv.ac.uk) by mailhub3.liv.ac.uk with esmtp (Exim 4.14) id 19cOBR-0004Vw-Nx for sc22wg5@dkuug.dk; Tue, 15 Jul 2003 12:41:25 +0100 Date: Tue, 15 Jul 2003 12:41:25 +0100 From: "J.L.Schonfelder" To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2860) Nesting of Submodules Message-ID: <2554413.1058272885@jls-rm-home.liv.ac.uk> In-Reply-To: <200307082322.h68NMJkX048431@dkuug.dk> References: <200307082322.h68NMJkX048431@dkuug.dk> 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/) *19cOBR-0004UU-UQ*RC1nr90Lidk* Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Basically I agree strongly with Van. Nesting of submodules to any depth desired by the user is desirable and to apply a limit is more difficult than to not have one. As Van points out we do not limit the number of procedures nor the depth of the call tree, nor do we limit the depth of the executable construct nest. It is mildly arrogant of us as standard writers to posit "I cannot think of any good reason for nesting internal procedures or the like, so I will limit the depth of nest that is allowed". Users can and do think of all sorts of perfectly good reasons why in their application our limits are a pain. Unless there is a very very pressing technical need for arbitrary limits in the standard we should not set them. I would also be very strongly opposed to requiring the containing descendant submodule to be named in the parent that defines its forward interface. This is unnessesary and simply makes it more complicated for the user to structure the program set. It adds yet another way in which the user can get it wrong without helping him get it right. Nor would it to my mind make processing any easier. On the contrary the processor would have further things to check. -- Lawrie Schonfelder Honorary Senior Fellow University of Liverpool 1 Marine Park, West Kirby, Wirral, UK, CH48 5HN Phone: +44 (151) 625 6986