(j3.2006) Some Questions About Function Returnign a Pointer is a Variable (Was:: READ unit ambiguity)

[Dick Hendrickson]

On Fri, Mar 2, 2012 at 1:21 PM, Craig Dedo <craig at ctdedo.com> wrote:
>> -----Original Message-----
>> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On Behalf Of
>> Bill Long
>> Sent: Friday, March 02, 2012 11:08
>> To: fortran standards email list for J3
>> Subject: Re: (j3.2006) Some Questions About Function Returnign a Pointer is a
>> Variable (Was:: READ unit ambiguity)
>>
>> On 3/2/12 10:55 AM, Craig Dedo wrote:
>> >
>> > ? ? The new rule, "function reference returning a pointer is a variable",
>> > seems like a Really Bad Feature, more like a defect that needs fixing. ?I have a
>> few questions.
>> >
>> > ? ? I tried looking up "function reference returning a pointer is a
>> > variable" in the Fortran 2008 standard and I could not find it. ?Where is this
>> defined?
>> >
>>
>> See 6.2, definition of "variable".
>>
>> Cheers,
>> Bill
>
> ? ? ? ?Thank you very much, Bill, for pointing me in the right direction. ?I made the
> mistake of only looking for "variable" in the index, not for <variable> as a syntax term.
> My bad.
>
> ? ? ? ?Unfortunately, nobody has yet ventured to answer my other questions. ?I would like
> to see as many people as possible attempt to provide some serious answers to these
> questions. ?I especially would like to hear from implementors.
>
> ? ? ? ?Are there are any people brave, or foolish, enough to make an attempt?
>

I'll take a stab, although I'm not sure I remember correctly.  I think
it is related to the problems in calling large "solver" type
subroutines that have many (50 or so) dummy arguments and where the
absence, presence, allocation status, or pointer association status
controls whether or not the solver does something.  As a practical
matter it was hard to code CALL statements.  You can't have an
unpresent argument unless you have a CALL where that argument is
physically not written in.  Ditto, it was found to be hard to deal
with unallocated/unassociated arguments.  The desire was to have an
unallocated argument act like a notpresent argument, and there was no
practical way to do that.  If 10 or 20 arguments needed to have
different physical presentness, then you needed 2**20 (or whatever)
call statements nested in a 10 or 20 deep IF-THEN-ELSE.  People just
can't write those programs.

I believe Van was the driver for this.  Originally he proposed a way
to add arguments one at a time to the call.  Something like
          magic-word  Call xxx (first, second,
          other-magic-word  IF (some condition)
                                                   third = that
                                        ELSE
                                                  third = this
                                        ENDIF
...
         end magic-word
This would produce
             CALL XXX (first, second, this...)
or
             CALL XXX (first, second, that....)

You'd need 10 or 20 IFs to deal with 10 or 20 interesting arguments,
but they wouldn't be nested.

That didn't look like a promising solution.  So an alternative was to
do something like
        CALL xxx (first, second, function( some condition, this, that)...)
but that didn't help much unless the function could return pointers or
whatever and have them be dereferenced or not as part of the CALL.

As I recall, the motivation wasn't particularly aimed at defined
operators in ordinary assignments.  That was just a natural
consequence of the fact that expressions can be used anywhere.

At least, that's what I remember.

Try looking for some of Van's papers from 04 or 05 or so.  There's
bound to be motivation in there.

Dick Hendrickson