(j3.2006) (SC22WG5.3819) [ukfortran] Ballot on the technical content of the TR
Thu Dec 11 12:50:44 EST 2008
> 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
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
More information about the J3