This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: GNU Fortran and the Fortran Standardization Process, generally
[Fortran 2003 implementation slowness and many half-implemented standards]
N.M. Maclaren wrote:
Yes and no. Most of the minor enhancements (e.g. I0 in formats) got in
fairly fast,
Yes, I concur that a lot of the small features are very useful. And, I
think the practice shows that some features got adopted very soon by
both compilers and compiler/Fortran users.
On the other hand, certain features are missing such as: restricting
the variables which are host associated, collective support for
coarrays, better C interoperability (union, "void *", array
descriptor), short-circuit evaluations "AndThen"/"orElse", better
type checking (restricted value set, units), more mathematical
functions (cf. C's TR24747), better support for heterogeneous systems
(GPGPU), generic programming (templates, macros), ...
Yes. How many of those are omissions that should NOT be filled is
another question, and 10 people will have 12 opinions between them ....
I listed - on purpose - more useful additions and less useful ones, ones
which many would like to have and ones which only few want, simple and
complex ones, ones which will come sooner (two TRs) and others which
will come later as part of Fortran 2013 - or (for the good or the bad)
never.
Thus, there is also some pressure and merits of adding new features,
with both the danger of bloating the language and creating too
specific features; but with not adding useful ones, the language will
also become less attractive.
I am far more concerned with adding features that break old and useful
properties or add "gotchas". Fortran 2003 C interoperability is a mess
in that respect, because it C's ill-defined object lifetime and type
compatibility rules sneak into Fortran by that route; unions would be
another, unless VERY carefully specified.
I think adding new features always have the tendency to create gotchas.
With regards to breaking old features, I am happy that Fortran mostly
added features in such a way that old programs still work. I think
supporting C unions is not trivial - and one can argue whether they
should be supported, but I listed them because there is some (probably
low) demand for it and some vendor extension (based on STRUCTURE)
seemingly allows for it.
Despite all the problems with C, I think the additions for better
interoperability with C (compared to pre-F2003) was overdue, given that
accessing C libraries from Fortran or Fortran libraries from C is common.
(I think PGAS support via coarrays is a feature which besides its
immediate usage [which might be disputed] has also the advantage to
raise visibility of the language and makes it more attractive.)
I am doubtful. My experience in predicting which fashionable ideas get
adopted and which sink without a trace is poor - that's emotion, not
engineering.
Well, I listed them as advantage - but it might well be temporary one.
In any case, there seems to be a lot of demand for this feature - from
the point of a compiler user and vendor, it makes sense to support it
soon, given that it is in the standard and that there is demand for it.
Whether it was the right decision to include it at all, is another
question, which only the future will tell. I think now that coarrays are
in, improving the collective support makes sense. Whether shared-memory
thread support or GPU(-like) support should go in, is another question.
Another question, which seems to be still unclear is how to support
heterogeneous systems like IBM's CELL or more recently (and currently
very hot) GPUs. I don't see them vanish any time soon, but on the other
hand, things are still in a flux and even with C (which seems to be more
actively supported than Fortran), many solutions and language(
extension)s exist and are used. I would like to see a better Fortran
support for GPUs, though this might be better done outside the Fortran
standard - similar to MPI, OpenMP, etc. which are also not part of the
language standard.
We have had over 40 years of programming languages adding
parallelism, and so far most models have sunk - and none have established
themselves in widespread usage. [ If people want to start a threading
thread, I suggest taking it elsewhere - it's too complicated for here! ]
(I think - despite of all the gotchas, both posix threads and OpenMP are
also successful. But otherwise, many techniques have died for several
reasons; often e.g. because the technique was restricted to a single
vendor or platform. The other question is also whether extension need to
be in the language standard, or could be in separate specs - such as
OpenMP, MPI or POSIX threads [of those, only OpenMP requires compiler
support].)
One problem I see with coarrays is also that it is a single-language
parallelization - contrary to MPI - which makes it more difficult in
mult-language projects.
C++ is adding a tightly-coupled threading model and, if the fashionable
set follow that, Fortran will get damned for being stuck back in the
dark ages with PGAS. Of course, C++'s model is both older in concept
and MUCH less scalable, but who lets facts get in the way of prejudice?
I think other C++0x features, which are currently under (late stage)
consideration, will be also fun ...
Tobias