From jls@liverpool.ac.uk Wed Sep 22 19:19:06 1993 Received: from mail.liv.ac.uk by dkuug.dk with SMTP id AA10139 (5.65c8/IDA-1.4.4j for ); Wed, 22 Sep 1993 15:32:21 +0200 Received: from 138.253.31.200 by mailhub.liverpool.ac.uk with SMTP (PP) id <03305-0@mailhub.liverpool.ac.uk>; Wed, 22 Sep 1993 14:30:37 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <9309221329.AA03523@uxb.liv.ac.uk> Subject: Re: (x3j3.1993-241) Re: pot pourri To: bill@amber.ssd.csd.harris.com (Bill Leonard) Date: Wed, 22 Sep 93 14:29:31 BST Cc: SC22WG5@dkuug.dk (SC22/WG5 members) In-Reply-To: <9309211704.AA13673@amber>; from "Bill Leonard" at Sep 21, 93 1:04 pm X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 Bill Leonard and Jerry wrote and I could not resist the temptation to rise to the bait! > > > Date: Thu, 16 Sep 93 16:19:34 CDT > > From: jwagener@amoco.com (Jerrold L. Wagener) > > > To X3J3 - > > > As to Jim's question (and I'm going to catch a *lot* of flack for this) - > > bravo. What are we worried about here? that the string module will > > succeed? that it will fail? It's time to quit cutting bait and find out. Here! Here! > > An excellent question, Jerry. As one of the opponents of the string > module, I'll give my viewpoint. > > > OK, so it's not perfect, but it's pretty good. To quote Voltaire: "The > > perfect is the enemy of the good." Ditto! I claim that most of the standards defects are the result of general defects in F90 and the philosophical restriction imposed by the requirement that the standard be defined in such a way as it could be implemented in conforming F90. I believe the restriction to be very important. It is the essential requirement that makes the core+modules architectural approach viable. It allows the core to be mandatory on all vendors and the modules optional, but it still protects the user. If their particular vendor does not provide a particular optional module, a portable implementation is possible and available. The standard is not however the module. It is the definition of the module interface, and as such could be implemented as an integral part of the processor environment in as optimised a manner as possible. The point of standardisation in this way is: a. The core language is not compelled to grow ever larger and larger. b. A user not interested in a particular facility is not compelled to have it cluttering up their program name and entity space. c. The user who is interested in the facility obtains access to it in a manner which is consistent and portable. The varying string standard is a first test case for this paradigm, and I believe it is sufficient (just) to demonstrate that it can and does work. The deficiencies that are clearly present should be fixed by correcting the general deficiencies in F90 when it is revised. The string standard can then be improved by its subsequent revision. > > What most people seem to have lost sight of is the purpose of > standardization. Why are we trying to standardize the string module now? > No one is stopping anyone else from using the module that Lawrie developed. > Go ahead, use it. But why do we need a standard now, before anyone has had > sufficient experience with Fortran 90 or with this particular string module > to tell if it is the right model? REMEMBER we are standardising the interface definition not my particular known to be less than optimal example implementation. If we look at the interface then we are not indulging in wild flights of fanciful innovation. The functionality for manipulating varying length strings has been about for decades. All the standard is doing is translating a minimal set of this into the Fortran 90 context. The technical question of whether the actual interface defined is the right one is the question that has been or should have been the subject of technical proposals and comments on technical (CD ballots) of the past few years. In this context I have to mis-quote the Beatles, "I got by with a little help from my friends", and I think the interface as defined by the current DIS is pretty reasonable. The innovation is doing this in the context of F90 and also implementing a version in F90, which I think is probably the first serious use of F90 for such a programming task. However, even that is not all that revolutionary. I have implemented packages of similar facilities before in Algol 68. > > > To remain competitive we need innovation such as the string module > > represents; in promoting innovation we must risk failure and reward, > > not discourage, risk takers. > > Standards are not *supposed* to be innovative, they are promulgated for > STABILITY. If the string module doesn't become a standard, then what? > Will no one use varying-length strings? No. Users can use it *now*; > what's stopping them? It's even written in standard-conforming Fortran 90! This is a major area of philosophical disagreement. In the IT area standards have to be innovative to some extent. Not "wide blue sky" stuff. That I leave to computer science and Xerox Parc, etc., but we need to keep standards upwith and if possible a little bit ahead of user demand or we risk the Babel syndrome or a high cost dialect management problem. > > In fact, premature standards DISCOURAGE innovation. If the string module > becomes a standard, hardly anyone would be foolish enough to propose, let > alone build, a competing model, regardless of how much better it might be. > How would we feel if Henry Ford had insisted on making the Model T a > standard for automobiles? More importantly, would we still be driving > Model Ts? No doubt someone will say that all standards are voluntary, but > it is nearly impossible (not surprisingly) to ever get a *competing* > standard, so hardly anyone would bother trying. While there is *no* string > module, there will be incentive for users and vendors to try different > ones, or different variations on the same basic idea. (Several vendors and > users have expressed the opinion that varying-length strings should be a > built-in type to the language. If the string module becomes a standard, I > seriously doubt such a possibility will ever be tried.) > > A standard can promote innovation only if it provides a well-established > basis on which higher-level products can be developed. Standards are > usually promulgated for mature technologies, where innovation has slowed or > stopped and it is now time to move on to other things. But if a standard > attempts to "lock in" an emerging or developing technology, innovation is > discouraged and the technology languishes. > > The very fact that the string module is the first (and only) attempt to > build a varying-length string facility for Fortran 90 is indication that we > haven't explored all (or even most) of the possibilities. I suggest that > Fortran 90 users have all they need for now. Use the string module, as > Lawrie has developed it. Or develop your own, if you want. If users > accept Lawrie's, and vendors start providing their own (optimized) > versions, *then* standardize it. But I bet, when that time comes, the > result will be substantially different from Lawrie's module. And that will > mean that innovation has won. The standard is not overly constraining, in common with all Fortran standards the vendor is permitted to extend and add to the facilities as long as these do not conflict with those defined in the standard. The standard provides a portable minimum. Without the standard there no portable defined facility except for a bit of public domain code; vendor provision will be different (you all do it differently what ever it is unless required to do it the same). If the facilities provided for varying length strings in Fortran are the wrong ones, then say so. And say what facilities should have been provided and define them. It is a bit late to be doing it at the DIS level, but if there are fundamental deficiencies it is better to fix them now than after the IS is published. The question of standardising this functionality in this way was settled by international vote in 1988/9. This is no longer a productive debate. -- 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