(j3.2006) Interesting F2003-ism

[Bill Long]

Aleksandar Donev wrote:

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

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

Still there.

>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 
perspective.


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

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.

Cheers,
Bill


-- 
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...
URL: http://j3.scs.gmu.edu/pipermail/j3/attachments/20070226/90613633/attachment.html