From bill@amber.ssd.csd.harris.com Wed Sep 22 10:38:54 1993 Received: from travis.csd.harris.com by dkuug.dk with SMTP id AA18428 (5.65c8/IDA-1.4.4j for ); Wed, 22 Sep 1993 20:38:14 +0200 Received: from amber.ssd.csd.harris.com by travis.csd.harris.com (5.61/harris-5.1) id AA20300; Wed, 22 Sep 93 14:38:57 -0400 Received: by amber (5.61/CX/UX-5.0) id AA04486; Wed, 22 Sep 93 14:38:54 -0400 Date: Wed, 22 Sep 93 14:38:54 -0400 From: bill@amber.ssd.csd.harris.com (Bill Leonard) Message-Id: <9309221838.AA04486@amber> To: jls@liverpool.ac.uk Cc: SC22WG5@dkuug.dk In-Reply-To: <9309221329.AA03523@uxb.liv.ac.uk> (jls@liverpool.ac.uk) Subject: Re: (x3j3.1993-241) Re: pot pourri X-Charset: ASCII X-Char-Esc: 29 > From: "Dr.J.L.Schonfelder" > Date: Wed, 22 Sep 93 14:29:31 BST > 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. If we know that it will need revision, then it is not ready for standardization. The whole *point* of standardization is (or should be) so that users can write portable code that doesn't have to change every time they get a new compiler or computer system. Changing the standard will not serve that need. > REMEMBER we are standardising the interface definition not my particular > known to be less than optimal example implementation. And so far no known "optimal" example implementations have been demonstrated. We don't even know yet if that's possible. That indicates to me that it is still too early to standardize this interface. > All the standard is doing is translating a minimal set of > this into the Fortran 90 context. And all Fortran 90 did was translate (mostly) long-known programming concepts into a different language, and look how many mistakes were made and how long it took to do it! > 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. Well, I did raise this question long ago, but the momentum of the standardization process was already too well-developed to have any effect. Anyway, this argument ASSUMES that a proposed standard can be rejected only on the grounds of a technical flaw, not on the issue of whether it is needed or not. I bet I could propose a standard for transport ships to Mars, and no one would hardly even think about challenging its necessity. If they did, I'd just say "well, how do you want me to change the standard to change your vote to Yes?". > 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. That admission, all by itself, is sufficient reason to delay standardizing the string module. How can we possibly know what the problems might be? Jerry said the string module is "good enough", but that statement must be based more on faith than experience. How does he (or anyone) know whether it's good enough? It has harly been tested. A few users have used it in relatively small applications. To be worthy and ready for standardization, it should first be tested by hundreds of users in many different applications, from small to very large. Then *they* can tell us what's missing, what's wrong, what's unnecessary, and what's right. > > 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. But what are we paying to avoid these problems? I think the costs of premature standards far outweigh those of multiple dialects. It takes DECADES to get rid of a bad standard; in some cases, you *never* get rid of it. Besides, I think the computer industry has changed a lot since the days of proprietary systems, which I think is the source of Lawrie's concerns of multiple dialects. I would like to cite an example from another area of the industry to illustrate my points. In the Macintosh world, there are several emerging mechanisms for applications to exchange data. Apple has "Publish and Subscribe"; Microsoft has "Object Linking and Embedding", and a third company (whose name I can't remember) has something called EGO (can't remember what that stands for now). No doubt each of these has its merits and demerits. No doubt each of the vendors would say their product is "good enough". But should *one* of them be standardized now? No, because we haven't had sufficient experience with any of them to say positively that the entire industry should be locked into one of them. Quite possibly, if there is a future standard, it may be an amalgam of all of them. One thing is sure, though: if any one of them were standardized now, it would discourage vendors from inventing a better mechanism. Lawrie pointed out that some of the problems with his proposed module arise from forcing it to be written in standard Fortran 90. As I previously pointed out, several X3J3 members have expressed the opinion that varying-length strings should be a built-in data type. I think that is a viable alternative only as long as there is no string module standard. I would like to see more usage of the string module (and Fortran 90 generally) before I decide which alternative is best. Who knows, perhaps users will say that the deficiencies in the string module are outweighed by it being an optional part of the language. Or perhaps they will find those deficiencies unbearable and *demand* that it be a built-in type. Why not leave the options open for now? > 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). I don't see why any vendor would do anything for awhile, seeing as how there is a published solution -- namely, your string module. Anyway, if a vendor wants to experiment with a built-in type, or some other approach, I don't think the existence of the string module standard would prevent him from doing that; it would just discourage it. I for one would hate to see that happen. > If the facilities provided for varying length strings in Fortran are the > wrong ones, then say so. How can I say so? I have no experience on which to base an answer. I say, let's get the experience first, *then* make a standard based on hard facts. In closing, I will note that the only justification given for this standard is that "vendors will do it different if we don't standardize it now". That seems a poor justification to me. For one thing, it could just as well apply to computer architectures. How come we didn't just all standardize on the Intel 8080 and be done with it? :-) Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com These opinions and statements are my own and do not reflect the opinions or positions of Harris Corporation. ------------------------------------------------------------------------------ Let's put an end to infinity. ------------------------------------------------------------------------------