Prev: calling a subroutine with a "string constant"
Next: Help with executing strings in fortran
From: robin on 9 May 2010 21:56
"Zaak" <zbeekman(a)gmail.com> wrote in message news:afec00e6-69f8-40ac-9958-4bade30481ac(a)n15g2000yqf.googlegroups.com...
| 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)?

That is unsafe.
How can the READ be executed when the argument is omitted?
It cannot, of course.

If ERR were an optional dummy argument, there would need to be a test
for that condition, and in that case, the READ could not be executed.


From: robin on 9 May 2010 22:28
| "Zaak" <zbeekman(a)gmail.com> wrote in message news:afec00e6-69f8-40ac-9958-4bade30481ac(a)n15g2000yqf.googlegroups.com...
|| 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)?
|
| That is unsafe.
| How can the READ be executed when the argument is omitted?
| It cannot, of course.
|
| If ERR were an optional dummy argument, there would need to be a test
| for that condition, and in that case, the READ could not be executed.

Consider also the following :-

If ERR were actually optional, and were used in the READ
any subsequent tests on this variable would FIRST require a
test to ensure that the corresponding argument were present.

So what is the point of your suggestion? You would still
require a test to determine whether the optional dummy argument
had a corresponding argument that was supplied.


From: Dieter Britz on 10 May 2010 05:24
Zaak 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).
>
> 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.

That reminds me of something I reckon Fortran could do with. I programmed
in PL/1 for some years, and that language has a nifty feature, the "on"
condition. You set this so that upon a certain error occurring, the
program reacts in a certain way, rather than crashing. I miss this in
Fortran. It exists only in special forms, such as IOSTAT in some calls,
but not in general.
--
Dieter Britz (dieterbritz<at>yahoo.com)
First  |  Prev  | 
Pages: 1 2
Prev: calling a subroutine with a "string constant"
Next: Help with executing strings in fortran