From jls@uxb.liv.ac.uk Tue Feb 9 10:35:00 1993 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA29431 (5.65c8/IDA-1.4.4j for ); Tue, 9 Feb 1993 11:35:55 +0100 Received: from mail.liv.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Tue, 09 Feb 93 10:35:16 GMT Received: from uxb.liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <25655-0@mailhub.liverpool.ac.uk>; Tue, 9 Feb 1993 10:35:19 +0000 From: jls Message-Id: <488.9302091035@uxb.liv.ac.uk > Subject: HPF 1.0 chapter 9 To: hpff-comments@cs.rice.edu Date: Tue, 9 Feb 93 10:35:00 GMT Cc: SC22WG5@dkuug.dk (SC22/WG5 members) X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 Comment on HPF 1.0 Chapter 9 As was indicated in my comment on the general philosophy of HPF, I strongly disapprove of subsets as a matter of principle. I also disapprove of the particular subset described in chapter 9. So much so that I would recommend rejection of any subset only systems in any procurement where I was responsible for purchasing advice. The subset as defined does not provide a sufficient addition to Fortran 77 to be usefully considered as a step towards Fortran 90. The lack of modules and module procedures, but the inclusion of forms that require explicit procedure interfaces, imposes unacceptable, onerous and most likely error prone coding practices on the user. It also forces the use of storage association as the only mechanism for coding global data requirements. In addition the lack of user defined generic procedures makes for very much more difficult name management problems for the user and the service provider, not to mention the loss of convenient precision control. The module as a vehicle for providing clean, clear and non-storage associated global data is I would have thought of very considerable relevance to HPC. It is therefore not even consistent with the self imposed criteria used to establish the subset to exclude modules. Further, without modules all procedures that require explicit interfaces, which again will be many if not most, if storage association is to be avoided, will have to declare the interfaces explicitly in interface definitions in every program unit using the procedures. This is an onerous chore for most users and one that is likely to result in errors due to inaccurate duplication of the text. The use of textual include could to some extent make this more palatable but the interface definitions will need to be compiled multiple times rather than the once that would be the case were these to be declared in a module. Further where there are a set of related cross-calling procedures all of which require explicit interfaces by far the best way of packaging and presenting these to the processor is to include the whole set as module procedures in a module. All the problems associated with the handling of explicit interfaces are managed in the simplest posssible way. I would claim that these are all very serious issues for HPC codes and coders. Almost by definition such codes are large and have many procedures. The management and maintenace of consistent interfaces is a critical factor in the production and maintenance of large codes. The Fortran 90 module and module procedures are a major step in helping in this process. An HPF subset that significantly delayed the widespread implementation of this facility in Fortran processors would be highly regrettable. Assuming that modules and module procedures are included then generic procedures should also be allowed. There are two compelling reasons for this. Firstly, generic procedures, particularly if the specific names are made PRIVATE greatly ease the name management problem which can become very serious where large programs are built using libraries of facilities from different sources. Secondly, it is a feature of many problems that as the problem becomes larger it requires more arithmetic precision for its solution. In many cases a large problem may well be solved by programs developed and tested in a different environment from that used for its final production runs. It is therefore highly desirable for it to be easy and error free for the program to be moveable from single to double precision and back. Generic procedures vastly assist this process. One of the main reasons why this capability was introduced into Fortran 77 intrinsics was this precision switching problem. It was very difficult to make the change from SIN to DSIN every time the precision was changed. The Fortran 90 generic procedure facility extends this capability to user written procedures. This is again a capability that is of considerably relevance to HPC. Finally, I do not believe any of these facilities are particularly difficult to implement. On the contrary their full support in the existing NAG Fortran 90 compiler is proof that they are actually quite straight forward. I reiterate my strong oposition to subsets in general. The main effect is not to speed up implementation of a subset but to delay the implementation of the full language. The particular subset is, I believe, seriously deficient even by its own criteria and would not even constitute an acceptable interim facility. -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk