(j3.2006) Still illegal in F08?

[Van Snyder]

On Wed, 2010-01-06 at 17:33 -0800, Malcolm Cohen wrote:
> Van Snyder wrote:
> > Everything about automatic variables is well-provided-for by allocatable
> > variables and IF constructs.
> 
> I don't agree.  You don't need any IF constructs for what we currently consider 
> to be automatic variables, and for very good reason.  Needing an IF construct 
> marks your suggestion out as being different in kind from what we allow now.

Allowing an optional dummy argument to be an actual argument associated
with an optional dummy argument of a specification function doesn't
necessarily require an IF construct.  There might be one in the
specification function, or there might be a reference to the MERGE
intrinsic.

> > If there was a good argument for automatic variables, I don't understand
> > why there aren't good arguments for making them more usable.
> 
> Well I don't think your suggestion would make them more usable at all.  To the 
> extent that it waters down compile-time checkability, in fact it worsens the 
> user experience.

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?  The processor can know the dummy is optional because
specification functions are required to be pure, and C1280 requires the
interface of a pure procedure to be explicit if the procedure is
referenced in a context that requires it to be pure.

> ... (Mostly one wants to execute different statements if optional 
> arguments are not present anyway.)

... and that's what got me started down this track.  In the case that
code doesn't get executed when an optional argument is not present, the
work variables it would use don't need to be there.

The case I have requires a work variable that gets a column of an
optional argument if that optional argument is present.  Then, that work
variable is sent to another subroutine -- or not if the optional
argument isn't present.  This requires writing out two almost-identical
calls -- the only difference being whether the work variable appears. 

If we had done something more about computing whether actual arguments
corresponding to optional dummy arguments are considered to be present,
something like "present(a) ? b" (or the same notion in a functional
syntax), or if we had allowed a section of an absent optional dummy
argument to be an actual argument corresponding to an optional dummy
argument, with the section considered to be absent when its base object
is absent, I wouldn't need to write out two calls.

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.  Rather than have
the maintenance headache, I plan to revise the code to use null pointers
or zero-size arrays, instead of absent optional arguments (which are the
cleanest from the point of view of the procedure that has them), to mean
"don't do this."

My first plan was to avoid pointers, to reduce optimizer confusion, and
use zero-size arrays instead.  I tried a dimension
"merge(size(x),0,present(a))" but that's not going to be legal until
2008 (you've convinced me it will be).  So I'm stuck with an IF
construct (actually six of them, for six work arrays) instead of six
trivial automatic variable declarations.  This is ugly, but far less
ugly than a 64-way if-elseif...elseif-else-endif structure (with six
references to PRESENT and varying numbers of .NOT. in each IF or ELSEIF)
and almost-identical calls in each branch.