(j3.2006) Proposals 13 and 17 in 13-244r1

[Van Snyder]

On Wed, 2013-06-12 at 10:37 +0900, Malcolm Cohen wrote:
> >Proposal 13 in 13-244r1 deals with conditional expressions.  The second
> >functionality is a form that allows to compute whether an actual
> >argument is present.  This should be extended to specifiers in I/O
> >statements, ALLOCATE, DEALLOCATE, LOCK, ....  The easiest way to do so
> >is to change the nomenclature for those specifiers from "appear" to
> >"present".  This would have the additional salubrious effect of allowing
> >optional arguments to specify their values.
> 
> Proposing to allow absent optional arguments as i/o specifiers has nothing to do 
> with proposal 13.  It is a new proposal.

Actually, it's at least nine years old (04-180), but new for 201.

Because this leads to the same sort of combinatorial explosion that
motivated part 2 of proposal 13 in the first place, our code has local
variables for each specifier we'd like to use in this way, fills them
with default values, then fills the ones that correspond to present
dummy arguments.  That's for the ones that would be intent(in) if I/O
etc statements were procedures.  For the ones that would be intent(out),
we have local variables, then copy their values to appropriate present
dummy arguments.

The alternative, which I consider to be rather ugly, is to extend part 2
of proposal 13 to compute whether a specifier is considered to appear.
"Present" seems easier and prettier.

> Given that i/o specifiers are few in number there is also no great motivation, 
> though I agree that it would be more convenient... but I think it will only be 
> useful in a vanishingly small number of cases; I can count the number of times I 
> have seen IF (PRESENT(...)) THEN around alternative i/o statements, except for 
> UNIT=* vs UNIT=N where this would not help anyway, on the fingers of one foot.

My feet have far more fingers than Malcolm's.

> >Proposal 17 deals with allowing a rank-1 extent-R explicit-shape array
> >with constant bounds to specify the bounds of a rank-R array in a
> >specification statement.  This should be extended to include the bounds
> >in an ALLOCATE statement.
> 
> This is a plausible extension of proposal 17.
> 
> (I will note that if the intent is to copy the bounds of another array of the 
> same type and type parameters, Fortran 2008 already provides that functionality 
> with the MOLD= specifier.  But there is no help for copying the bounds of 
> another array of different type.)

Right.  One case where we would find it useful is where the bounds are a
dummy argument -- not the bounds of a dummy argument.

> Cheers,