(j3.2006) Interesting F2003-ism

[Aleksandar Donev]

Hi,

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 
question anyway.

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.

Best,
Aleks