Prev: calling a subroutine with a "string constant"
Next: Help with executing strings in fortran
From: Zaak on 7 May 2010 14:35
Is there a reason why you can pass down optional arguments through
many procedure calls (including intrinsic procedures) but if you want
to put a Fortran statement within one of these procedures and pass it
the optional variable as an optional statement argument (i.e.
READ(*,*,iostat=err) my_var, where err is defined, say, INTEGER,
INTENT(out), OPTIONAL :: err)? It seems to me that if intrinsic
procedures can handle this without incurring too much overhead,
statements such as OPEN, CLOSE, READ, WRITE, ALLOCATE, etc. should be
able to. After all, they probably won't be in the innermost loop of a
computationally intensive routine (like, say a
SUM(my_var,dim=my_optional_var) statement could be).

It would be very useful for for providing a choice as to whether
errors are detected (say we run out of memory for an allocate
statement, or out of disk space for a write statement) and passed back
up the call stack to the main/driver program, or calling subroutine,
or just let the code fail and view any trace back and error messages
provided by your compiler. This would be useful for unpolished in-
house or under development codes because you would have the option of
not passing the error variable to the topmost (or one of the outer)
calling routines and then if you segfault, run out of memory, specify
a bad file name, etc. you will get the compiler provided error msg
rather than some cryptic numeric error code you have to diagnose. On
the other hand, in a very polished, production version of a code,
maybe you want to give the user an abort, retry, fail option. To do
this now one would have to declare two equivalent Fortran statements,
and sandwich them in an IF( PRESENT(var) ) THEN statement, which gets
exceedingly verbose very quickly.

I guess I missed the boat in terms of the '03 and '08 standard
specification, but it would be really nice (in my mind) to improve
Fortran's exception handling capabilities, or at least empower the
developer to write useful, powerful, and generic exception handling
routines. Another example of this is being able to provide derived
type structure components, or possibly run-time variables to STOP
statements.

Any thoughts, comments or suggestions welcome.
From: glen herrmannsfeldt on 7 May 2010 15:09
Zaak <zbeekman(a)gmail.com> wrote:
> Is there a reason why you can pass down optional arguments through
> many procedure calls (including intrinsic procedures) but if you want
> to put a Fortran statement within one of these procedures and pass it
> the optional variable as an optional statement argument (i.e.
> READ(*,*,iostat=err) my_var, where err is defined, say, INTEGER,
> INTENT(out), OPTIONAL :: err)? It seems to me that if intrinsic
> procedures can handle this without incurring too much overhead,
> statements such as OPEN, CLOSE, READ, WRITE, ALLOCATE, etc. should be
> able to. After all, they probably won't be in the innermost loop of a
> computationally intensive routine (like, say a
> SUM(my_var,dim=my_optional_var) statement could be).

There was discussion some time ago about whether the propagation
of OPTIONAL applied to intrinsic routines, but I believe that it
was decided that it did.

As for your question, I believe it is that OPTIONAL was added
at the same time as the intrinsic routines with optional arguments.
That made it easy to add the ability, though there may be an
efficiency cost to it. A well designed library might supply a
faster routine that doesn't need to handle the optional argument,
at least for the case when it is known absent.

I am not sure in which version of the standard OPTIONAL was added,
nor which version added IOSTAT. I believe that IOSTAT came
either earlier or in the same version of the standard.
If it came later, there might have been some thought to adding
the feature you ask for.

-- glen
From: Richard Maine on 7 May 2010 17:20
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> There was discussion some time ago about whether the propagation
> of OPTIONAL applied to intrinsic routines, but I believe that it
> was decided that it did.

I hope it wasn't much of a "discussion" as it is pretty straightforward;
yes, it does.

However, that's largely irrelevant to the OP's question. He was not
asking about procedures, but rather about the keyword specifiers in
Fortran statements. Specifiers are not arguments. They might look
simillar in some cases, but they are not the same thing and do not
follow the same rules.

As for why optional dummy arguments could not apply to such specifiers
with the "obvious" interpretation, I couldn't say. Probably nobody
pushed for it hard enough. I see no particular reason why it couldn't
be.

> I am not sure in which version of the standard OPTIONAL was added,

f90

> nor which version added IOSTAT.

f77

But I don't think that has much relevance. If people wanted to add the
feature, it could have been done easily enough, I'm quite sure.
Priorities are another matter, and much more likely to be the real one.
Features don't get added just because they could be done. People have to
actually propose them and defend their cost/benefit.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Zaak on 7 May 2010 17:40
On May 7, 5:20 pm, nos...(a)see.signature (Richard Maine) wrote:
> glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
> > There was discussion some time ago about whether the propagation
> > of OPTIONAL applied to intrinsic routines, but I believe that it
> > was decided that it did.
>
> I hope it wasn't much of a "discussion" as it is pretty straightforward;
> yes, it does.
>
> However, that's largely irrelevant to the OP's question. He was not
> asking about procedures, but rather about the keyword specifiers in
> Fortran statements. Specifiers are not arguments. They might look
> simillar in some cases, but they are not the same thing and do not
> follow the same rules.
>
> As for why optional dummy arguments could not apply to such specifiers
> with the "obvious" interpretation, I couldn't say. Probably nobody
> pushed for it hard enough. I see no particular reason why it couldn't
> be.
>
> > I am not sure in which version of the standard OPTIONAL was added,
>
> f90
>
> > nor which version added IOSTAT.
>
> f77
>
> But I don't think that has much relevance. If people wanted to add the
> feature, it could have been done easily enough, I'm quite sure.
> Priorities are another matter, and much more likely to be the real one.
> Features don't get added just because they could be done. People have to
> actually propose them and defend their cost/benefit.
>
> --
> Richard Maine                    | Good judgment comes from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle           |  -- Mark Twain

I want this feature. I can defend the benefits. The costs, well not
my department of expertise, but it shouldn't be too bad.
From: glen herrmannsfeldt on 7 May 2010 18:35
Richard Maine <nospam(a)see.signature> wrote:
> glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

>> There was discussion some time ago about whether the propagation
>> of OPTIONAL applied to intrinsic routines, but I believe that it
>> was decided that it did.

> I hope it wasn't much of a "discussion" as it is pretty
> straightforward; yes, it does.

I believe that was decided pretty fast, but finding the words
in the standard takes a little longer.

> However, that's largely irrelevant to the OP's question. He was not
> asking about procedures, but rather about the keyword specifiers in
> Fortran statements. Specifiers are not arguments. They might look
> simillar in some cases, but they are not the same thing and do not
> follow the same rules.

I thought he was asking why they didn't follow the same rules.

> As for why optional dummy arguments could not apply to such specifiers
> with the "obvious" interpretation, I couldn't say. Probably nobody
> pushed for it hard enough. I see no particular reason why it couldn't
> be.

The OP was guessing that it would be for performance reasons.
Routines with optional arguments have to check at each call for
each argument and take the appropriate action. For a simple
function, that could be more than it actually takes to do the
desired operation. For I/O, as the OP says, it is likely a small
part of the time.

>> I am not sure in which version of the standard OPTIONAL was added,

> f90

>> nor which version added IOSTAT.

> f77

That is what I thought, but I wasn't sure. It seems harder to go
back and change a previous feature than to add complication to
a new feature.

> But I don't think that has much relevance. If people wanted to add the
> feature, it could have been done easily enough, I'm quite sure.
> Priorities are another matter, and much more likely to be the real one.
> Features don't get added just because they could be done. People have to
> actually propose them and defend their cost/benefit.

Well, if you just want to add the ability to supply optional arguments
to IOSTAT, maybe not so bad. But there are many options in I/O
statements, and likely some are more complicated than IOSTAT.

Last week, I was looking up the ASYNCHRONOUS attribute, and the
options on I/O statements that go with it. It seems that for
I/O statements (but maybe not for OPEN) the ASYNCHRONOUS specifier
is an initialization expression for compiler optimization reasons.

There are five times in the Fortran 2003 standard that compiler is
mentioned, two of them regard ASYNCHRONOUS, one IEEE floating point,
one VOLATILE, and one for modules.

-- glen
 |  Next  |  Last
Pages: 1 2
Prev: calling a subroutine with a "string constant"
Next: Help with executing strings in fortran