From jls@uxb.liv.ac.uk Thu Jan 14 15:19:09 1993 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA22632 (5.65c8/IDA-1.4.4j for ); Thu, 14 Jan 1993 16:34:53 +0100 Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 5525; Thu, 14 Jan 93 16:36:37 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 7404; Thu, 14 Jan 93 16:36:36 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 1145; Thu, 14 Jan 93 15:34:07 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 2503; Thu, 14 Jan 93 15:25:43 GMT Via: UK.AC.LIV.UXB; 14 JAN 93 15:18:28 GMT From: "Dr.J.L.Schonfelder " Via: uxb.liv.ac.uk (uxe.liv.ac.uk); Thu, 14 Jan 93 15:19:11 GMT Message-Id: <18675.9301141519@uxb.liv.ac.uk > Subject: HPF proposal To: SC22WG5@dkuug.dk(SC22/WG5 members) Date: Thu, 14 Jan 93 15:19:09 GMT X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 I have just extracted copy of the latest HPF proposal document and from a superficial reading a few points have struck me. 1. They define a subset and a full HPF, this I believe to be highly undesirable. The experience with F77 was ample demonstration of this. The subset is likely to be more popular with implementors than users and then we get a piecemeal and hence unportable move to extension in the direction of the full language. In general this delays the full language. 2. There is a glaring deficiency from my point of view with the proposed subset. They leave out generic procedures from F90 on the grounds that these are of no interest to HP applications. I think this is very much in error. It is a well known numerical truism that as problems get bigger they tend also to get less well conditioned. Whereas smaller developmental and/or test cases may run quite well in single precision, the larger production codes regularly need DP for their solution. Being able to easily and efficiently switch back and forth between precisions can and does lead to much more efficient use of machine resources and this requires library codes that are generic over REAL(KIND). Generic procedures are not difficult to implement and they do not have a run time cost since by that stage the calls have been replaced by specific ones. F90 has static overloading for this reason rather than the much easier for the user of late binding generics. 3. A significant number of new intinsics are added and a new class of procedure called extrinsic is defined. This latter appears to be the interfaces to a set of procedures that will necessarily be written in a low level language to do explicit parallel type things such as message passing. In both cases I believe it would be very much better if these interfaces were defined as being accessed via an HPF module. This would allow much better control over the namespace problems associated with extra intrinsic names and would allow the user who is not interested in the use of such facilities not to be concerned with them at all. I hope to spend some time over the weekend doing a more careful read. I think WG5 should make an official comment on this proposal since if HPF is successful we will come under considerable pressure to incorporate much of it in a future Fxx standard. I would not like to be saddled with too many things that could have been better given some considered input from us now. -- 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