(j3.2006) (SC22WG5.3819) [ukfortran] Ballot on the technical content of the TR

Aleksandar Donev donev1
Thu Dec 11 12:50:44 EST 2008

Hi Jim,

> This is also one of the things I don't like of this TR: to have TYPE(*) 
> mixed with descriptors.  It breaks the TKR matching rule in Fortran for 
> no good reason.
The TKR matching rule is not a rule handed to us by god. It is a rule 
that makes sense as a first guess and is easy to write in textbooks, but 
it is *exactly* the rule that causes lots of problems. You were the one 
that brought IGNORE_TKR up! That attribute, which we are trying to 
standardize in a nice way here, *ignores* and thus explicitly violates 
the so-called "rule". The whole point of TYPE(*) and DIMENSION(..) is to 
do away with this rigid TKR-matching rule that forces people to write 
100+ wrappers, one for each type and kind, for *no good reason*. Sorry, 
I think it is you that has "no good reason" to fear.

> Many vendors do have type and rank info in the descriptor.  But again 
> descriptors are sort of "compiler internal structures" that meant to be 
> used by compilers only, not for regular users to play with.
There are whole languages based on descriptor-type argument passing 
which are in fact very nice to use---for example Python. Descriptors are 
for arrays what "objects" are for user-defined types. The descriptors 
carry useful information, that is important to the user. It does not 
mean the user has to be able to *directly* manipulate it (we don't allow 
that---it all goes through an API), but the user needs to be able to 
inquire and modify.

Consider CLASS(*). The user can inquire about the type, which the 
compiler reads from the descriptor. They can also change the type (say 
via a pointer assignment). So they are in fact manipulating type 
descriptors, but in safe and syntactically-pleasing ways. That is 
because they do it from within Fortran. Interop is by definition ugly, 
and not safe. C users can already do a lot of bad things, and there is 
no way for the Fortran compiler to guard against it. C users can also do 
a lot of cool things, like send an array ever a network, which Fortran 
cannot. The goal here is to let C users do those cool things as safely 
as possible.

There is a compromise between safety and functionality that has to be 
found. Otherwise you end up with rules like TKR matching that are *too 
rigid* and thus constrain good programmers as well as bad ones.

Do you think that passing-by-address (what INGORE_TKR) does in most 
existing compiler is safe?!? Once you have an address in C, you can do 
all sorts of wrong things. What prevents that? Allowing the type and 
shape info to be obtained directly from the actual and be passed to the 
dummy increases safety, not reduces it. As to C calling Fortran, 
assumed-shape arrays are no more safe than pointer or allocatable ones. 
The C programmer can put all kinds of wrong info in the descriptor. For 
example, strides that are prime numbers.

All I've heard from you is fear and tentative complaints without any 
solution. It sounds like you don't want a TR at all? If you do, propose 
something specific instead of just saying "I don't like". If you don't 
want a TR, say so directly since otherwise I am wasting my time trying 
to convince you--you have made your mind up already. I am being honest here.


Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev

More information about the J3 mailing list