From aurelio.pollicini@cen.jrc.it Wed Jun 22 12:27:35 1994 Received: from cen.jrc.it (dicscs1.jrc.it) by dkuug.dk with SMTP id AA03267 (5.65c8/IDA-1.4.4j for ); Wed, 22 Jun 1994 10:27:42 +0200 Received: from cen.jrc.it (relay.jrc.it) by cen.jrc.it (4.1/SMI-4.1) id AA15889; Wed, 22 Jun 94 10:26:16 +0200 Received: from sad.isei.jrc.it (uranus) by cen.jrc.it; Wed, 22 Jun 94 10:26:54 +0200 From: Aurelio Pollicini Date: Wed, 22 Jun 94 10:27:35 +0200 Message-Id: <28153.9406220827@sad.isei.jrc.it> To: sc22wg5@dkuug.dk Subject: Goodbye! X-Charset: ASCII X-Char-Esc: 29 To: All Nice People met at Fortran Meetings From: Aurelio Pollicini Date: June 23rd 1994 Subj: Sincere Wishes of Successful Work I have just addressed an internal note to my boss on a quite familiar subject - Fortran. The note itself has no particular focus on matters being discussed at present. However, I mail it to the WG5 distribution list, because it seems to me a good occasion to motivate, with just a few more words, my absence at the next meeting in Edinburgh. I'm not complaining any of the reasons which have concurred to the withdrawal of support for membership. Rather, I'm committed to look forwards: that's life! I keep, anyway, a rich set of records about past meetings and a long list of very, very good friends. I always had very good time at Fortran meetings and what I will miss more is the direct personal contact with all of you. As you understand, I'm not missing a meeting, I'm out of the Fortran revision business. For sure, the memory of all the friends I count in WG5 and X3J3 remains as the most effective Fortran advertizing. I take it as implied that there may be new occasions to meet some of you again... one never knows. Hello to everybody, possibly to be extended to any old friend no longer on the mailing list, from the crowd of the Pollicini: my wife Bruna, our children (who had occasionally accompanied us) Alessandra, Dario, Paolo, and Aurelio (aurelio.pollicini@jrc.it) PS (to Jeanne Martin & to Rich Kelble) Because document distribution is expensive, after the mailing following the Edinburgh meetings, please cancel my name from both WG5 and X3J3 distribution lists. PS (to David Muxworthy) I would appreciate remaining on the email distribution. If it doesn't raise problems, this would still allow me to hear news about both people and Fortran. I will myself notify the SC22WG5 postmaster, when to discontinue the mailing of messages. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ From: Aurelio Pollicini Date: Tue 22nd June 1994 Subject: Fortran Checker "ftnchek" \it{Except the grain of wheat falling into the ground die, it abides alone; but if it die, it bears much fruit.} (John XII, 24) Martyn, Dave passed on to me the documentation of the checker he's using and I had a look at it. Just two considerations which matter to our present situation (and to my past involvement in Fortran): a) \it{Is Today's Horizon Nearer than Yesterday's?} At first glance, the checker presents well. Its chartered intent stands on strong words, that is \it{ to assist the user in finding semantic errors.} (\it{unused}, \it{undeclared}, and \it{uninitialized} are everybody's nightmares). Even after a deeper reading, the evaluation is that for Dave it is worth using it. Since the checker is very pragmatic, there is a good probability that some potential flaw, undetected on the base platform, is pointed out. All too evident is the benefit obtained in porting the application across different platforms. Anyway, pragmatic is at a lower confidence rate than systematic. Let me explain my concerns. How refined may it be a static tool for catching \it{every} case of uninitialized entity? So, I first guessed, as the reading was progressing. Then I met, one after another a list of realistic statements: - \it{Sometimes ftnchek makes a mistake about this warnings. Usually it errs on the side of giving a warning where no problem exists, ...} (Beware Dave, careful interpretation is mandatory!); - \it{ftnchek does not do a thorough enough analysis of the calling sequence to know which routines are called before others.}; - also, about unsaved Common blocks, \it{A block can also become undefined between two successive calls of the same subprogram, but ftnchek is not smart enough to tell whether a subprogram can be called more than once}; - finally, as it is typical of static analysis - even for very good static analysers - \it{ftnchek does not analyse the program flow, but assumes that statements occurring earlier in the text are executed before the following ones.} Beyond the undeniable usefulness of tools such as \it{ftnchek}, pragmatic improvement of software is insufficient in the domain of safety critical applications. We have to seek for much more deterministic approaches to the systematic measurement of software process improvement. b) \it{Quo Vadis Fortran?} Browsing over the 31 parameters available for invoking "ftnchek", from a Fortran 90 point of view, it is quite disappointing to remark that: - only one is looking at the future (i.e. \it{pure} function check); - four of them deal with situations mastered by \bf{procedure interface} and \bf{independent compilation} (i.e. attribute consistency through procedure call); - two of them deal with situations mastered by \bf{module} and \bf{automatic array} (i.e. global objects vs. local workspace made unequivocally separate concepts); - one of them intends to address the problems overcome by \bf{implicit none}; - seven of them are explicitely related to violations to Fortran 77 (some with one eye backward to f66 features); - four of them provide functionality any good compiler is expected to support (i.e. standard conformity checking, cross-references, symbol table symmary, and invoked procedures); - while the remaining ones are not tied to evolution of Fortran (seven simply devoted to the operation mode). This may be considered a measure of the low attention paid to the move forward Fortran 90 had inteded to promote. The driving engine of the \it{real} evolution - paraphrastic allusion to \it{industry} - is not interested \bf{at all} in state of the art solutions, marginally interested in innovation, mainly (maybe only) interested in backward compatibility. Such a policy is so well assimilated by users - ours in particular - that their only concern is the survival of yesterday's practice, paying almost no attention to what may be expected for tomorrow. You probably remember, in my draft of November 88 on \it{Procedural Languages for Scientific Applications}, I wrote \it{... backward compatibility leaves the door open to bad techniques and involuted methods whose use contrasts with the attempt of conciliating portability and efficiency.} Now, I come to say that all valuable efforts to promote Fortran advance are likely to wreck against the fear of losing past wares (or, should I say \it{pastware}? ). Maybe, the spirit of backward compatibility has to die, for the spirit of modern language design to bear the intended fruit! Unfortunately, this is unlikely to happen shortly. Therefore, it is less painful for me to have left the business. PS. I put this on hard support just in case you may wish to circulate it, in any form, within our institute. _____________ Copy: -> Dave