(j3.2006) Interesting F2003-ism
Sat Feb 24 04:46:35 EST 2007
As Craig said, it is probably not the time to discuss the TR yet...but,
let me respond to this bit:
> Let me make a prediction. I predict that Aleks will write a paper
> suggesting something like IGNORE(RANK).
Such a paper was already written by Aleks a while ago, it used
DIMENSION(). And it did not pass...It is a non-trivial thing to get
working and make sufficiently functional. The main point of my argument
is that I do not think anything (substantial) needs to be changed in
Fortran (which is not to say I think rank genericity is a bad idea, I
just think it is more complicated than doing the TR right).
I have no intention of writing papers to standarize Cray's vendor
extensions (IGNORE something or other), we've done more than enough of
that for F2008. I am not in the business of philosophical fights and
predictions of the future of programming languages. We are doing
language design here, and the issue at question is a very simple one:
A C routine that has a descriptor handle as an actual *can* interoperate
with multiple Fortran interfaces. Should it be allowed to have multiple
Fortran interfaces, so that it can be called from Fortran with both,
say, a rank-1 real array, and a rank-3 integer array actual?
I obviously think the answer to this is a very clear yes. If Bill says
no, there better be a good reason other than "I don't think there is
enough (Cray) users that would use that (now)" (that is not an argument
that has any relevance to good language design). The current standard no
but only because of some dubious rules in ch. 16 that (are claimed to)
aim at avoiding linker errors, which do not exist in the example under
The next question for the TR is: Will our interoperable descriptor
contain TKR info? If yes, which bits, T, K, and/or R? The old proposal
includes rank info. This already requires some vendors to change their
dope vectors. Lots of them include also type info (TK really). I want
this to be included (details TBD) in the interoperable descriptor, so
that C routines can make use of it. It makes for very lean, clean,
powerful, and efficient interfaces between *modern* Fortran and C/C++
libraries. And it makes life very simple for both the Fortran
programmer, that can just calls the routine, and for the C programmer
writing a Fortran interface to their library, writing only one routine
instead of 250 or some such crazy number.
If TK info is not included, I claim neither should rank.
These are technical issues, not DOE labs verus the rest of the world or
Fortran versus C++ waffle.
More information about the J3