(j3.2006) Still illegal in F08?

[Van Snyder]

On Thu, 2010-01-07 at 02:21 -0800, Malcolm Cohen wrote:
> Van Snyder wrote:
> > I take your point of not using optional arguments willy-nilly.  Would it
> > really reduce checkability by a measurable amount to allow an optional
> > dummy argument to be an actual argument associated with a dummy argument
> > of a specification function, provided a requirement is added that the
> > corresponding dummy argument of the specification function has to be
> > optional?
> 
> That strikes me as reasonable actually.

I'll put it in my 2013 wishlist.

> > The "two calls" case is the degenerate case.  I have four such
> > arguments.  That means I need 16 cases, to handle the 16 possible
> > combinations of present and not present.  I've just gotten a requirement
> > for two more derivatives.  That makes 64 cases now.
> 
> I thought this sort of thing was why we've added passing null pointers to 
> optional nonallocatable nonpointer dummies being treated as nonpresent instead 
> of an error.

That was a kludge of a half measure (actually more like a 6% solution)
because we declined to provide a method for an explicit "the actual
argument isn't here even thought there's text in the actual argument's
position" runtime computation, which was part of the conditional
expression proposal.  Something like <cond> ? <arg> to mean "if <cond>
is true then <arg> is the actual argument, else the actual argument is
not present."

What happens in the subroutine I'm wrestling with is

1.  It has a rank-2 optional dummy argument, named "sps_path," which
when present modifies the method of computation.

2.  If sps_path is present, a row of it is copied to a local variable
names "sps," and an additional computation is done there (so I can't
just take a pointer to sps_path -- or nullify the pointer).

3.  If sps_path is present, the next lower level routine is called with
sps in the argument list; otherwise, the next lower level routine is
called without sps in the argument list.

4.  There are actually four such arguments, so the selection of how to
call the next lower level routine is 16-wide.  This kind of thing
happens in numerous places in my 300,000-line code.  Each time I
discover a new one I gnash my teeth.  I leave them alone until the
scientists say something like "Oh, we now want derivatives with respect
to the dependence of line width on temperature" or "the absorption cross
section for relative humidity is actually nonlinear so you need to pass
the mixing ratio."

I can't have a null pointer corresponding to an optional nonpointer
dummy argument in Fortran 95 or 2003, so in other similar routines, I've
changed the dummy argument to a pointer and used "associated" instead of
"present" to control whether certain computations are done, or I've
passed an array of either zero or nonzero size, with zero meaning "don't
do the computation."  I don't like the pointer solution because it has
the potential to subvert optimizers.

What I would like to be able to do, hopefully in Fortran 2013, is

1.  If sps_path is not present, create sps as an automatic array with
zero size, else create it with the column dimension of sps_path (which
happens to be the same as a dimension of another nonoptional argument).
The cases when I don't have such an independent clue were the stimulus
for wanting either conditional expressions, or lazy evaluation for
actual arguments of "merge," so I could write "present(sps_path) ?
size(sps_path,2) : 0" or "merge(size(sps_path,2),0,present(sps_path))"
for the dimension of sps.

2.  Yes, I could make sps allocatable instead of automatic, but
        2a.  It requires several more statements, especially given that
        our style guideline requires checking the status of explicit
        allocations and deallocations.  This causes a second-order
        headache, which was the stimulus for allowing pointer vs.
        allocatable as a last-resort generic resolution criterion.
        2b.  My hope is that someday processors could take some
        advantage of automatic variables to make one trip to the
        allocator for all the automatic variables in a scope, and then
        calculate under-the-covers pointers to access the appropriate
        places that each variable occupies in the allocated block.

3.  Call the next lower routine with an explicit computation to specify
whether the "sps" argument is to be considered to be present in the
called routine, something like "present(sps_path) ? sps".  I have a
large number of such low-level routines, and it's a real headache to dig
into each one and change "if(present..." to "if(associated..." or
"if(size(...)/=0)..." (which doesn't work for scalars) and make
corresponding changes in the declarations and calling routines.

> Cheers,