(j3.2006) Interesting F2003-ism
Mon Feb 26 20:12:05 EST 2007
Aleksandar Donev wrote:
>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.
Well, it is not currently a Cray extension. It is a directive, and one
supported by more vendors than just Cray.
>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?
As said earlier, the idea of forcing the Fortran programmer to write (I
believe Craig was claiming ) thousands of interfaces to use this feature
is just not reasonable. This is the WRONG solution to this problem.
>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).
Feedback from the TR vote suggested that the information visible to the
C programmer be in terms of C concepts. So the TK information should be
in terms of names line int, long, float. double. ... which correlate to
a combination of type and kind information from the Fortran programmer's
>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++
That's assuming such C/C++ libraries would be written. I'm convinced
that the initial use will be the other way, since there is already
existing Fortran code with assumed-shape, allocatable, and pointer dummy
arguments that can be called from C.
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3