From wclodius@lanl.gov Mon Mar 6 02:49:30 1995 Received: from sstcx1.lanl.gov by dkuug.dk with SMTP id AA18212 (5.65c8/IDA-1.4.4j for ); Mon, 6 Mar 1995 17:53:52 +0100 Received: from [128.165.58.113] (clodius [128.165.58.113]) by sstcx1.lanl.gov (8.6.10/8.6.9) with SMTP id JAA09680; Mon, 6 Mar 1995 09:49:30 -0700 Date: Mon, 6 Mar 1995 09:49:30 -0700 Message-Id: <199503061649.JAA09680@sstcx1.lanl.gov> X-Sender: clodius@sstcx1.lanl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Lawrie Schonfelder From: wclodius@lanl.gov (William B. Clodius) Subject: Re: F2K Cc: comp-fortran-90@mailbase.ac.uk, SC22WG5@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 >On Thu, 2 Mar 1995 11:30:38 +0000 (GMT) Dr A.C. Marshall wrote: > >> From: Dr A.C. Marshall >> Date: Thu, 2 Mar 1995 11:30:38 +0000 (GMT) >> Subject: F2K >> To: comp-fortran-90@mailbase.ac.uk >> >> I thought I chuck in my two-cents regarding Fortran 2k. >> >> I also think that making INTENT / INTERFACEs mandatory is too heavy handed. >> People KNOW that these features are a good idea and anybody with any sense >> will use them. The last thing we want to do is to scare off F77 users which >> will happen if their program will not compile under an F2K compiler. >> >> Personally, one feature I would like to see is a new visiblity attribute, >> say, RESTRICTED, which when applied to module entities allows them to be >> visible in other modules but not in programs or procedures. This would >> allow for even greater software reuse, enhanced efficiency and security. >> >> Adam Marshall >> >I think Adam has a very good idea here. When I was writing the string module >and >subsequently looking at using it. It was clear that any reasonable standard >module of this sort could only provide a basic set of facilities and for >safety >and flexibility the internals of the module are rightly hidden. However, when >writing use programs in specific applications areas there were some special >extra facilities that could be produced more efficiently if access to the >internals could be made. You want to have the extra dependent module have >access >but for all the usual reasons you dont want to export the internals to the >end-user program units. The idea of a RESTRICTED visibility attribute which >allowed importing modules to access such entities but not other program units >would provide this capability. >Adam, >why dont you write this up as a formal request to WG5 for consideration as a >F2K >requirement. > >-- >Dr.J.L.Schonfelder >Director, Computing Services Dept. >The University of Liverpool, UK >e-mail J.L.Schonfelder@liv.ac.uk >phone: +44(51)794-3716 >fax: +44(51)794-3759 An even better solution I believe would be child modules similar to Ada's child packages. The problem with RESTRICTED is that you have to decide in advance which components to make accessible to USErs of the module. It is liable to result in the incremental modifications of modules that is similar to what happens with C++'s parent classes, hurting reusability. Instead Ada's child package recognizes that only someone who is veery familiar with the "package", should know the PRIVATE components and such a person should be allowed to write code that interacts with them, provided the child package is defined so that code (certainly programs possibly component modules) which uses the parent module and doesn't use the child package is unaffected by the child package. The child module might be defined with the syntax MODULE PARENT_MODDULE_NAME%CHILD_MODULE_NAME ... END MODULE and used of course as USE PARENT_MODDULE_NAME%CHILD_MODULE_NAME to convey the notion that the child module defines what is effectively part of the parent module. In addition I would like to see Fortran add READ_ONLY accessibility for module components, i.e., components whose values can be determined by users of the modules but whose values cannot be changed by such users except through the interface routines. I would also like to see Fortran implement more flexible data hiding for components of data types, i.e., allow some components to be private, some public, and some read_only. In the long run, if Fortran modifies user defined types to become classes, read_only components would be indistinguishable to users from "parameterless" (class only) functions, in the spirit of encapsulation. #################################################################### # # # William B. Clodius Phone (505) 667-3105 or 665-9370 # # Los Alamos Natl. Lab. NIS-1 FAX (505) 665-7395 # # PO Box 1663, MS-D466 Group Office (505) 667-2701 # # Los Alamos, NM 87545 email wclodius@lanl.gov # # # #------------------------------------------------------------------# # # # NIS-1: Nonproliferation and International Security Division / # # Space and Atmospheric Physics Group # # # ####################################################################