 |
 |
On Thu, 2010-08-05 at 19:14 -0700, Vivek Rao wrote: > Especially someone who has proposed many features in Fortran 2008 > should be aware that several compiler vendors have decided not to > produce compilers beyond Fortran 95 (except for some TR's). > Silverfrost is one example. Lahey, which allied with Fujitsu, is > another. Maybe someone can comment about Pathscale. I was told by Fujitsu, by way of Lahey, that they had no plans for development of the 32-bit Linux product, and this included maintenance. My questions about their 64-bit Linux product, or Windows products, or products for Fujitsu supercomputers, were greeted with silence. Fujitsu, Silverfrost, Pathscale and Absoft do not participate in Fortran standardization, or this mailing list as far as I can tell. Perhaps Vivek could convince them to tell Ian Chivers their plans. > Fortran 2008 has been finalized, right? Yes, two years ago. That's why it's called "Fortran 2008" instead of "Fortran 2010." > The committee should restrict itself to maintenance mode until full > F2008 compilers are available. Why? With the exception of coarrays, Fortran 2008 was essentially a maintenance project. Although the table of contents of ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1828.pdf is more than two pages long, everything described therein except coarrays were minor projects. A significant reason that Fortran fell into bad odor in the computer science community between 1966 and 1990 was that it had stagnated. Fortran 90 added free source form, modules, dynamic storage, derived types... and then stagnated again at Fortran 95. Notwithstanding that Fortran 2003 was a major increment, especially by providing for object-oriented programming, there are still things that Fortran lacks (from a computer-science standpoint) that other languages have. First in line would be a generic programming facility akin to C++ templates or Ada generic packages. Others would be a block-structured exception handling mechanism, assertions and other facilities for "programming by contract," a more complete type system.... For those who use Fortran for its targeted purpose, that is, scientific and engineering computing, a system of physical units would go quite some distance toward catching and correcting units-related errors at compile time, and to a certain extent at run time. Those who develop mathematical software that needs access to client code, such as quadrature evaluators, differential equations solvers, minimizers, nonlinear equation solvers... would welcome coroutines.... If ANSI and ISO committees had taken Vivek's advice in 2004 (and there were others offering the same advice), Fortran 2008 wouldn't have co-arrays, which are an enormous leap forward compared to PVM or MPI or HPC or OpenMP.