Newsgroups: comp.lang.fortran Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!mroussel From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel) Subject: Re: Fortran 90 status Message-ID: <1991May12.190710.9294@alchemy.chem.utoronto.ca> Organization: Department of Chemistry, University of Toronto References: <3246@travis.csd.harris.com> <1991May10.002337.22669@ariel.unm.edu> <16101@smoke.brl.mil> Distribution: comp Date: Sun, 12 May 1991 19:07:10 GMT In article <16101@smoke.brl.mil> chidsey@smoke.brl.mil (Irving Chidsey) writes: > Could we not agree to add to Fortran every 5 years or so those >new constructs which have proven to be valuable, discuss those directions >that might be desirable to explore next, but to only standardize on that >which was proven? I think this is an interesting idea. I hope Irving doesn't mind if I expand on it a bit. The current standard has two categories of constructs: "general" and "deprecated". (I'm not sure what terminology the standard actually uses. I trust my usage is clear enough. The second class corresponds to old language features retained only for compatibility and which may be removed in the next round of standardization, while the first category refers to everything else.) Perhaps the next round should have three classes: "general", "deprecated" and "exploratory". Implementation of exploratory features would be encouraged, but not required. We could throw into this new category anything we're not sure about but would like to try. We could probably agree on exploratory features faster than we could agree on general features since they wouldn't be perceived to be cast in stone. Exploratory features would also allow vendors who thought that the particular version espoused by the standard was somehow wrong (inefficient, or whatever) to explore alternate ways to deliver identical functionality. This would be a great stimulus to development of the language. Marc R. Roussel mroussel@alchemy.chem.utoronto.ca