Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!rpi!crdgw1!lamson From: lamson@sierra.steinmetz.ge.com (scott h lamson) Newsgroups: comp.lang.fortran Subject: Re: X3 Vote on Fortran 8x Message-ID: Date: 20 Oct 89 03:19:22 GMT References: <2192@convex.UUCP> <426@unmvax.unm.edu> Sender: news@crdgw1.crd.ge.com Distribution: comp.lang.fortran Organization: GE Corporate Research & Development Lines: 48 In-reply-to: brainerd@unmvax.unm.edu's message of 19 Oct 89 23:58:13 GMT > Walt Brainerd: >This vote will have many effects that could be _disastrous_ for the >ENTIRE Fortran community. I agree, except that before too long, there will not ONE recognizable Fortran community. There will be two seperate communities. Are all the people who voted for retaining Fortran-77 going to resign from X3J3 so we get on with 8x? (after all, f-77 is not subject to further change, so why stick around?) >It amazes me that people who claim to be experts >in the business of computing (or any other, for that matter) can formally >vote to change the basic goals and design specs of a project that is >in a final testing phase and believe that the product produced is consistent >with the new goals and specs. OK, so as long as this has happened, what is the best course to pursue now? What can we choose for goals under the altered circumstances. With all the reactionaries clinging to Fortran-77 forever, what can we do with Fortran-x not having to comprimise to keep everyone together? It has been too long waiting for a revised standard to undertake new initiatives at this point. But we could reconsider some things removed from the first draft standard in the spirit of comprimise. I would like to see parameterized derived types first, with perhaps limiting this to non-precision parameters. This would be useful for defining matrices as derived types, especially sparse or symmetric arrays of size n by n. Should we reconsider removing the depracated features sooner? And provide only the new source form, with a requirement that the processor include a filter to convert the old source form to the new source form. > ?? remember writing this Presley ?? > Then your favorite vendor >will be put in a position of which standard to implement and >FORTRAN could go the way of other languages that have gotten >into similar situations. >That could result in a real MESS! So, stay tuned for more >information from the WG5 meeting in Paris... The future >of FORTRAN may be being decided this week... -- Scott| ARPA: lamson@crd.ge.com Lamson| UUCP: uunet!crd.ge.com!lamson (518)387-5795| UUCP: uunet!sierra.crd.ge.com!lamson