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 |