Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!aunro!alberta!mts.ucs.UAlberta.CA!Al_Dunbar From: userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) Newsgroups: comp.lang.fortran Subject: Re: Fortran 90 status Message-ID: Date: 15 May 91 15:46:06 GMT References: <3246@travis.csd.harris.com> <1991May10.002337.22669@ariel.unm.edu> <16101@smoke.brl.mil> <1991May12.190710.9294@alchemy.chem.utoronto.ca> Organization: MTS Univ of Alberta Lines: 47 In article <1991May12.190710.9294@alchemy.chem.utoronto.ca>, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >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 Please! The quest for the current "standard" was already plagued with enough "exploratory" ideas under the guise of "standardizing existing practice". There is enough work for a standards committee already without adding the tasks of compiler design and R&D. There _should_ be a suitable forum somewhere for exploring new directions, but it isn't the standards committee. They will be lucky if there is even a wide enough base of understanding of the effects of the new features by the time the next round is underway. I like the 5-year idea, if only because it might tend to limit the scope of work to a reasonable amount. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "I disclaim disclaimers" CANADA | -------------------+-------------------------------------------