Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!unmvax!brainerd From: brainerd@unmvax.unm.edu (Walt Brainerd) Newsgroups: comp.lang.fortran Subject: Re: Two Fortran Standards Keywords: Fortran 8x Message-ID: <306@unmvax.unm.edu> Date: 26 Aug 89 16:57:48 GMT References: <282@unmvax.unm.edu> <1592@convex.UUCP> Organization: University of New Mexico at Albuquerque Lines: 36 In article <1592@convex.UUCP>, bleikamp@convex.UUCP (Richard Bleikamp) writes: > Walt, why do you feel that attempting to integrate Fortran 77 features with the > new 8x features (so both can be used concurrently) is a mistake? If you > want to replace the Fortran 77 standard, then you need to accomodate a > gradual migration to 8x features, as old programs are enhanced/updated > over time. By not allowing co-existance of new and old features you`re > forcing users to convert an entire sub-program at a time (if not entire > programs) to the "new" form in order to utilize new 8x features. It's likely > that this will slow user acceptance of 8x, except for new development. > In many cases it is a good idea to allow mixing of old and new features, when it assists migration, as you suggest above. But X3J3 has lost sight of that purpose and is mixing everything, whether it helps anyone or not, making the language unduly complex, when many people are asking for it to be simpler. Let me illustrate this with a recent change: allowing structures in common. At first glance, this seems like a good candidate. Structures (sort of like Pascal records) are new and maybe there would be some reason to put one in common. Now you look up the rules and find out that you can't do this if you have any of the parameterized intrinsic data types in the structure ("short" integers, specified precision reals, Kanji or Ascii or Ebcdic characters, etc). Recent e-mail discussions among X3J3 members suggest that even these restrictions are not sufficient to make things work. So the result of the whole exercise is that you really can't mix the new stuff and the old stuff anyway, except in some very special cases. Adding the "feature" increases the complexity, but worse is the addition of strange restrictions on its use that will be very difficult for a programmer to understand or remember. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800