(j3.2006) (SC22WG5.3797) [ukfortran] N1761, TYPE(*), BIND(C) and arrays

[N.M. Maclaren]

On Dec 9 2008, Bill Long wrote:
>
>> This is something that I subconsciously realised when reading N1761,
>> but only formulated what it was fairly recently.  Fortran does not have
>> the concept of a called procedure knowing anything about the properties
>> of its actual arguments (i.e. the objects and expressions in the calling
>> procedure).  The SOLE information available to a called procedure about
>> its arguments are in its OWN declaration (i.e. the properties of its
>> dummy arguments).
>
>That paragraph is so completely wrong that I'm just dumbfounded.   Do 
>you mean that if I inquire about the allocation status of a dummy 
>variable at the beginning of a subroutine, I get no information about 
>the allocation status of the corresponding actual argument?  Or the 
>pointer association status of a pointer? Or the extents of an 
>assumed-shape array?  None of this information is explicit in the 
>declaration of the dummy argument.  Of course, these are exactly the 
>cases the TR is intended to address.   No wonder you are finding it so 
>hard to understand.

No, I do not mean precisely what you say, but I do mean something very
close to it.  I used the word 'properties' because I was referring to
states that Fortran does not have a term for.  Let's summarise the
'properties' I was NOT referring to:

    1) Allocation and pointer status.  Yes, those transfer down fairly
reliably - they weren't the properties I was referring to - but it isn't
clear how N1761 handles such things with INTENT(OUT).

    2) Attributes.  The called procedure has no information about the
attributes of the actual arguments, where they are allowed to differ from
the attributes of the dummy arguments.

But let's skip both of those, because N1761 doesn't rely on them (much).

What I was referring to were the properties of array shapes/sections and
whether array arguments are expressions (and, if so, what kind).  Yes, N1761
is intended to address these, but it fails to do so.  In the following:

    REAL :: x(10)
    CALL Fred(x(m:n:k))

x(m:n:k) is a section of an explicit-size array, NOT an assumed-shape array.
2.1.3.4 makes it clear that the terms assumed-shape and assumed-size refer
only to dummy arguments, which x(m:n:k) most definitely isn't.

In order to make N1761 meaningful, you need to specify what the term
"assumed-shape" means for an argument passed as DIMENSION(..).  If you look
at the example program, you will see that it introduces some very nasty
questions about that.  If I wasn't in such a hurry, I am sure that I could
think up some much more evil ones ....

In other words, N1761 has started to use the term "assumed-shape" to refer
to actual arguments, without specifying what it means when used like that.


Alternatively, please ignore all of my commentary in that posting, and that
I have included above, and just answer the questions on that program.  Just
HOW is each of those arguments passed?



Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679