Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
procedure as optional argument?
52 views
Skip to first unread message
Phillip Helbig---undress to reply
May 31, 2012, 4:27:23 AM5/31/12
to
I've never had occasion to use this until now, and don't recall seeing
any examples. My guess is that a procedure dummy argument can be
optional just like any other. How would this be declared? A
hand-written INTERFACE block (I think this is the only time one needs to
write an INTERFACE block by hand; of course this is not necessary if the
routine is in a module which is used, but for library-type routines with
optional procedure arguments this can't be done) and an additional,
separate OPTIONAL statement?
any examples. My guess is that a procedure dummy argument can be
optional just like any other. How would this be declared? A
hand-written INTERFACE block (I think this is the only time one needs to
write an INTERFACE block by hand; of course this is not necessary if the
routine is in a module which is used, but for library-type routines with
optional procedure arguments this can't be done) and an additional,
separate OPTIONAL statement?
Arjen Markus
May 31, 2012, 5:08:39 AM5/31/12
to
Op donderdag 31 mei 2012 10:27:23 UTC+2 schreef Phillip Helbig---undress to reply het volgende:
I do not know if it is possible - checking for the presence or absence
seems odd too - but consider this alternative:
interface use_func
module procedure use_user_func
module procedure use_default_func
end interface
contains
subroutine use_user_func( f )
interface
real function f(x)
...
end function
end interface
...
write(*,*) f(1.0)
end subroutine use_user_func
subroutine use_default_func
write(*,*) sin(1.0)
end subroutine use_default_func
In other words: consider providing an interface uniting two
versions, one with the function dummy argument and one without.
Perhaps a bit more source code, but it will do the trick in
any case.
Regards,
Arjen
seems odd too - but consider this alternative:
interface use_func
module procedure use_user_func
module procedure use_default_func
end interface
contains
subroutine use_user_func( f )
interface
real function f(x)
...
end function
end interface
...
write(*,*) f(1.0)
end subroutine use_user_func
subroutine use_default_func
write(*,*) sin(1.0)
end subroutine use_default_func
In other words: consider providing an interface uniting two
versions, one with the function dummy argument and one without.
Perhaps a bit more source code, but it will do the trick in
any case.
Regards,
Arjen
Wolfgang Kilian
May 31, 2012, 5:16:28 AM5/31/12
to
module foo
abstract interface
integer function fi ()
end function fi
end interface
contains
subroutine apply_f (f)
procedure (fi), optional :: f
if (present (f)) print *, f ()
end subroutine apply_f
end module foo
-- Wolfgang
--
E-mail: firstnameini...@domain.de
Domain: yahoo
Phillip Helbig---undress to reply
May 31, 2012, 5:36:54 AM5/31/12
to
In article <90406972-ec54-462a...@googlegroups.com>,
> In other words: consider providing an interface uniting two
> versions, one with the function dummy argument and one without.
> Perhaps a bit more source code, but it will do the trick in
> any case.
This will work. However, a bit unwieldy in my case. I have a very long
list of arguments, most of them are optional. The idea is that the
calling program can provide a variable OR a function to calculate the
same quantity. Say you're calculating the time to fly from A to B. The
routine could get passed a constant windspeed as a variable, or a
function which would calculate windspeed as a function of time and
position. One could, of course, have in this function the special case
of constant wind speed, but would have to specify it in some non-obvious
way (say, the function could USE a module which contains the windspeed
and also a flag whether or not to use the windspeed from the module or
calculate it).
Arjen Markus <arjen.m...@gmail.com> writes:
> I do not know if it is possible - checking for the presence or absence
> seems odd too
Maybe it is.
> I do not know if it is possible - checking for the presence or absence
> seems odd too
> In other words: consider providing an interface uniting two
> versions, one with the function dummy argument and one without.
> Perhaps a bit more source code, but it will do the trick in
> any case.
list of arguments, most of them are optional. The idea is that the
calling program can provide a variable OR a function to calculate the
same quantity. Say you're calculating the time to fly from A to B. The
routine could get passed a constant windspeed as a variable, or a
function which would calculate windspeed as a function of time and
position. One could, of course, have in this function the special case
of constant wind speed, but would have to specify it in some non-obvious
way (say, the function could USE a module which contains the windspeed
and also a flag whether or not to use the windspeed from the module or
calculate it).
Phillip Helbig---undress to reply
May 31, 2012, 5:49:30 AM5/31/12
to
In article <jq7ctc$mig$1...@dont-email.me>, Wolfgang Kilian
What about this?
module foo
contains
real function f(x)
real :: X
f = 2*x
end function f
subroutine apply_f (f)
!optional :: f
!if (present (f)) print *, f ()
subroutine apply_f (f)
....................^
%F90-W-WARNING, This name has not been given an explicit type. [F]
at line number 7 in file DISK$SCRATCH:[HELBIG]BLA.F90;31
Since it is declared as a REAL FUNCTION in the same module, why isn't it
visible?
With the lines uncommented, I get:
subroutine apply_f (f)
....................^
%F90-W-WARNING, This name has not been given an explicit type. [F]
at line number 7 in file DISK$SCRATCH:[HELBIG]BLA.F90;32
if (present (f)) print *, f ()
...........................^
%F90-E-ERROR, This name has not been declared as an array or a function.
[F]
at line number 9 in file DISK$SCRATCH:[HELBIG]BLA.F90;32
print *, f ()
.........^
%F90-E-ERROR, This name has not been declared as an array or a function.
[F]
at line number 10 in file DISK$SCRATCH:[HELBIG]BLA.F90;32
I don't see why I don't get the last error above as well.
What I did in F77 was to hard-code the function name and have a flag
saying whether or not to use it:
IF (USE_FUNCTION) THEN
X = FUNCTION(Y)
ELSE
X = 5.0
ENDIF
But this needs the extra logical variable USE_FUNCTION and hard-codes
the function name. (I could have a non-optional procedure argument and
pass an arbitrary function, but then I would ALWAYS have to pass a
function name.)
<see...@domain.invalid> writes:
> No problem in F2003, consider this:
Won't work in F95. :-(
> No problem in F2003, consider this:
What about this?
module foo
contains
real function f(x)
real :: X
f = 2*x
end function f
subroutine apply_f (f)
!optional :: f
!if (present (f)) print *, f ()
print *, f ()
end subroutine apply_f
end module foo
With the lines commented out as above I get:
end subroutine apply_f
end module foo
subroutine apply_f (f)
....................^
%F90-W-WARNING, This name has not been given an explicit type. [F]
at line number 7 in file DISK$SCRATCH:[HELBIG]BLA.F90;31
Since it is declared as a REAL FUNCTION in the same module, why isn't it
visible?
With the lines uncommented, I get:
subroutine apply_f (f)
....................^
%F90-W-WARNING, This name has not been given an explicit type. [F]
at line number 7 in file DISK$SCRATCH:[HELBIG]BLA.F90;32
if (present (f)) print *, f ()
%F90-E-ERROR, This name has not been declared as an array or a function.
[F]
at line number 9 in file DISK$SCRATCH:[HELBIG]BLA.F90;32
print *, f ()
.........^
%F90-E-ERROR, This name has not been declared as an array or a function.
[F]
at line number 10 in file DISK$SCRATCH:[HELBIG]BLA.F90;32
I don't see why I don't get the last error above as well.
What I did in F77 was to hard-code the function name and have a flag
saying whether or not to use it:
IF (USE_FUNCTION) THEN
X = FUNCTION(Y)
ELSE
X = 5.0
ENDIF
But this needs the extra logical variable USE_FUNCTION and hard-codes
the function name. (I could have a non-optional procedure argument and
pass an arbitrary function, but then I would ALWAYS have to pass a
function name.)
Arjen Markus
May 31, 2012, 6:31:56 AM5/31/12
to
Op donderdag 31 mei 2012 11:49:30 UTC+2 schreef Phillip Helbig---undress to reply het volgende:
of Fortran 2003.
Regards,
Arjen
> In article Wolfgang Kilian writes:
>
> > No problem in F2003, consider this:
>
> Won't work in F95. :-(
>
What compiler are you using? Most seem to support at least these aspects
>
> > No problem in F2003, consider this:
>
> Won't work in F95. :-(
>
of Fortran 2003.
Regards,
Arjen
Ian Harvey
May 31, 2012, 8:00:16 AM5/31/12
to
Consider the following, which I think is just F95:
module foo
implicit none
contains
real function f(x) ! #1
real :: X
f = 2*x
end function f
subroutine apply_f (f) ! #2
f = 2*x
end function f
interface
function f(x) ! #3
real :: x
real :: f
end function f
end interface
optional :: f ! #4
if (present (f)) print *, f(3.0)
end subroutine apply_f
end module foo
The function body at #1 declares a function called f in the scope of the
end module foo
module.
In the subroutine statement at #2, the argument f has the same name as
the function-called-f-at-module-scope. Due to the rules of host
association the argument then hides the function - in between the
subroutine and end subroutine any references to f refer to the argument.
(If there was no argument called f then the
function-called-f-at-module-scope would be available inside the
subroutine through host association, in the event of a name clash the
host associated thing loses.)
The interface block at #3 then tells the processor what that f inside
the subroutine is. In this case it is a dummy procedure that is a
function. #4 also tells the processor that dummy argument is optional.
Without #3 the processor knows that there is a thing called f that is
local to the subroutine's scope, but it has no idea what it is - hence
you were seeing warnings and errors.
Phillip Helbig---undress to reply
May 31, 2012, 8:14:55 AM5/31/12
to
In article <0c4bb81b-6b30-412e...@googlegroups.com>,
nothing beyond that. It is several years old (but has been good
enough). I'm not sure if there is a newer version which supports more
features. However, I try to aim for the most recent standard which is
reasonably well supported. I seem to recall reading recently that IBM
has a complete F2003 compiler on AIX, but that is one of very few,
right?
Arjen Markus <arjen.m...@gmail.com> writes:
> What compiler are you using? Most seem to support at least these aspects
> of Fortran 2003.
I'm using the DEC/Compaq/HP compiler on VMS. It is full F95, but
> What compiler are you using? Most seem to support at least these aspects
> of Fortran 2003.
nothing beyond that. It is several years old (but has been good
enough). I'm not sure if there is a newer version which supports more
features. However, I try to aim for the most recent standard which is
reasonably well supported. I seem to recall reading recently that IBM
has a complete F2003 compiler on AIX, but that is one of very few,
right?
Phillip Helbig---undress to reply
May 31, 2012, 8:33:36 AM5/31/12
to
In article <k3Jxr.7771$%E2....@viwinnwfe01.internal.bigpond.com>, Ian
This works. (When in the same file, I had to have the module before the
test program calling apply_f. Otherwise works OK.)
> The function body at #1 declares a function called f in the scope of the
> module.
Right.
> In the subroutine statement at #2, the argument f has the same name as
> the function-called-f-at-module-scope. Due to the rules of host
> association the argument then hides the function - in between the
> subroutine and end subroutine any references to f refer to the argument.
OK.
> (If there was no argument called f then the
> function-called-f-at-module-scope would be available inside the
> subroutine through host association, in the event of a name clash the
> host associated thing loses.)
Right. I could call the dummy argument something else, but then it is
not clear why it should refer to f.
> The interface block at #3 then tells the processor what that f inside
> the subroutine is. In this case it is a dummy procedure that is a
> function. #4 also tells the processor that dummy argument is optional.
Right. This works. However, I really dislike writing interfaces by
hand; I prefer them to be automatic.
> Without #3 the processor knows that there is a thing called f that is
> local to the subroutine's scope, but it has no idea what it is - hence
> you were seeing warnings and errors.
OK.
Is there a way to do this without explicitly writing the interface? I
tried putting f in another module and using it, both from within foo and
from within apply_f. Neither work.
It is clear that declaring a local variable of the same name overrides
those inherited from elsewhere. However, the dummy argument, though it
doesn't specify a type and is not really a declaration, also overrides
this. Thus, the mere presence of a dummy argument overrides anything
from elsewhere, so there is no way to get the function definition via
USE.
This works. (When in the same file, I had to have the module before the
test program calling apply_f. Otherwise works OK.)
> The function body at #1 declares a function called f in the scope of the
> module.
> In the subroutine statement at #2, the argument f has the same name as
> the function-called-f-at-module-scope. Due to the rules of host
> association the argument then hides the function - in between the
> subroutine and end subroutine any references to f refer to the argument.
> (If there was no argument called f then the
> function-called-f-at-module-scope would be available inside the
> subroutine through host association, in the event of a name clash the
> host associated thing loses.)
not clear why it should refer to f.
> The interface block at #3 then tells the processor what that f inside
> the subroutine is. In this case it is a dummy procedure that is a
> function. #4 also tells the processor that dummy argument is optional.
hand; I prefer them to be automatic.
> Without #3 the processor knows that there is a thing called f that is
> local to the subroutine's scope, but it has no idea what it is - hence
> you were seeing warnings and errors.
Is there a way to do this without explicitly writing the interface? I
tried putting f in another module and using it, both from within foo and
from within apply_f. Neither work.
It is clear that declaring a local variable of the same name overrides
those inherited from elsewhere. However, the dummy argument, though it
doesn't specify a type and is not really a declaration, also overrides
this. Thus, the mere presence of a dummy argument overrides anything
from elsewhere, so there is no way to get the function definition via
USE.
Ian Harvey
May 31, 2012, 9:08:28 AM5/31/12
to
On 2012-05-31 10:33 PM, Phillip Helbig---undress to reply wrote:
> In article<k3Jxr.7771$%E2....@viwinnwfe01.internal.bigpond.com>, Ian
> Harvey<ian_h...@bigpond.com> writes:
>
>> Consider the following, which I think is just F95:
>
> This works. (When in the same file, I had to have the module before the
> test program calling apply_f. Otherwise works OK.)
It is a very common (in my experience ubiquitous bar one extreme corner
> In article<k3Jxr.7771$%E2....@viwinnwfe01.internal.bigpond.com>, Ian
> Harvey<ian_h...@bigpond.com> writes:
>
>> Consider the following, which I think is just F95:
>
> This works. (When in the same file, I had to have the module before the
> test program calling apply_f. Otherwise works OK.)
case that I'm aware of) requirement of implementations that the compiler
sees the module (either as a separate file, or earlier in the source
file) before it sees any use statements for the module.
...
> Is there a way to do this without explicitly writing the interface?
Not in F95 as far as I am aware.
In F2003 you could use a minor variant on the abstract interface
approach that Wolfgang posted upthread.
module foo
implicit none
contains
real function f(x)
...
end function f
subroutine apply_f(f_arg)
procedure(f), optional :: f_arg ! #1
...
end subroutine apply_f
end module foo
The procedure statement at #1 says that the interface of the dummy
end module foo
argument f_arg has the same characteristics as the interface of the
module procedure f. In Wolfangs example he provided an abstract
procedure to use as the template, above we hitch a ride using the
existing concrete function.
Arjen Markus
May 31, 2012, 9:15:30 AM5/31/12
to
Op donderdag 31 mei 2012 14:14:55 UTC+2 schreef Phillip Helbig---undress to reply het volgende:
> In article <0c4bb81b-6b30-412e...@googlegroups.com>,
and gfortran support most of the features of F2003 that I need (which makes
experimenting with these features quite convenient). And there are others
which similar support.
I do not use VMS myself, so I can not comment on the availability of
F2003 features on that platform.
Regards,
Arjen
> In article <0c4bb81b-6b30-412e...@googlegroups.com>,
> Arjen Markus writes:
>
> > What compiler are you using? Most seem to support at least these aspects
> > of Fortran 2003.
>
> I'm using the DEC/Compaq/HP compiler on VMS. It is full F95, but
> nothing beyond that. It is several years old (but has been good
> enough). I'm not sure if there is a newer version which supports more
> features. However, I try to aim for the most recent standard which is
> reasonably well supported. I seem to recall reading recently that IBM
> has a complete F2003 compiler on AIX, but that is one of very few,
> right?
As for a complete F2003 compiler, I think you are right, but both Intel Fortran
>
> > What compiler are you using? Most seem to support at least these aspects
> > of Fortran 2003.
>
> I'm using the DEC/Compaq/HP compiler on VMS. It is full F95, but
> nothing beyond that. It is several years old (but has been good
> enough). I'm not sure if there is a newer version which supports more
> features. However, I try to aim for the most recent standard which is
> reasonably well supported. I seem to recall reading recently that IBM
> has a complete F2003 compiler on AIX, but that is one of very few,
> right?
and gfortran support most of the features of F2003 that I need (which makes
experimenting with these features quite convenient). And there are others
which similar support.
I do not use VMS myself, so I can not comment on the availability of
F2003 features on that platform.
Regards,
Arjen
Gordon Sande
May 31, 2012, 9:40:48 AM5/31/12
to
On 2012-05-31 10:08:28 -0300, Ian Harvey said:
> On 2012-05-31 10:33 PM, Phillip Helbig---undress to reply wrote:
>> In article<k3Jxr.7771$%E2....@viwinnwfe01.internal.bigpond.com>, Ian
>> Harvey<ian_h...@bigpond.com> writes:
>>
>>> Consider the following, which I think is just F95:
>>
>> This works. (When in the same file, I had to have the module before the
>> test program calling apply_f. Otherwise works OK.)
>
> It is a very common (in my experience ubiquitous bar one extreme corner
> case that I'm aware of) requirement of implementations that the
> compiler sees the module (either as a separate file, or earlier in the
> source file) before it sees any use statements for the module.
There is the curious situation where a "failing" compilation sees the module
> On 2012-05-31 10:33 PM, Phillip Helbig---undress to reply wrote:
>> In article<k3Jxr.7771$%E2....@viwinnwfe01.internal.bigpond.com>, Ian
>> Harvey<ian_h...@bigpond.com> writes:
>>
>>> Consider the following, which I think is just F95:
>>
>> This works. (When in the same file, I had to have the module before the
>> test program calling apply_f. Otherwise works OK.)
>
> It is a very common (in my experience ubiquitous bar one extreme corner
> case that I'm aware of) requirement of implementations that the
> compiler sees the module (either as a separate file, or earlier in the
> source file) before it sees any use statements for the module.
towards the end of its processing and leaves a ".mod" file behind so that when
it is run again the the "failure" goes away and the compilation now succeeds.
Just a very awkward way to get things in an order suitable for the processing
method. This is an old problem with the need to scan object libraries multiple
times if the libraries are not in the "correct" order being an older example.
Some Linkers would rescan automatically until a full scan produced no new
object files found. Compilers do not do such things in my experience. That
is what make is used for but it does assume separate source files for things
that could be order dependent.
Richard Maine
May 31, 2012, 11:56:57 AM5/31/12
to
Arjen Markus <arjen.m...@gmail.com> wrote:
> Op donderdag 31 mei 2012 10:27:23 UTC+2 schreef Phillip Helbig---undress
to reply het volgende:
> > I've never had occasion to use this until now, and don't recall seeing
> > any examples. My guess is that a procedure dummy argument can be
> > optional just like any other. How would this be declared? A
> > hand-written INTERFACE block (I think this is the only time one needs to
> > write an INTERFACE block by hand; of course this is not necessary if the
> > routine is in a module which is used, but for library-type routines with
> > optional procedure arguments this can't be done) and an additional,
> > separate OPTIONAL statement?
>
> I do not know if it is possible - checking for the presence or absence
> seems odd too
I don't know what is so odd about it. Argument presence is orthogonal to
> Op donderdag 31 mei 2012 10:27:23 UTC+2 schreef Phillip Helbig---undress
to reply het volgende:
> > I've never had occasion to use this until now, and don't recall seeing
> > any examples. My guess is that a procedure dummy argument can be
> > optional just like any other. How would this be declared? A
> > hand-written INTERFACE block (I think this is the only time one needs to
> > write an INTERFACE block by hand; of course this is not necessary if the
> > routine is in a module which is used, but for library-type routines with
> > optional procedure arguments this can't be done) and an additional,
> > separate OPTIONAL statement?
>
> I do not know if it is possible - checking for the presence or absence
> seems odd too
any matter if the argument being a data argument. Anyway, yes, that's
perfectly fine.
For f95, you do end you having to write an interface body, which I don't
like. At least you need that to get an explicit interface for the dummy
rpocedure. If the dummy does not need an explicit interface, you can
just go with the EXTERNAL statement instead of an interface body, but I
don't much like that either.
As discussed in the other replies, f2003 provides what I see as
"cleaner" alternatives using the new PROCEDURE statement. The PROCEDURE
statement is much more parallel in form to type specification
statements, including the allowance for atributes such as OPTIONAL. You
can use an abstract interface with a PROCEDURE statement. That still has
you writing an interface body, but at least you can then potentially
reference that abstract interface in multiple places instead of having
to repeat it each time. Alternatively, you can use the feature of the
PROCEDURE statement that says, in essence, "use the same interface as
this other procedure, whose interface you already know." That avoids
having to write an interface body at all. But all of those require
f2003.
For f95, you are stuck with either an interface body or the external
statement/attribute. Also for f95, you have to use a separate OPTIONAL
statement (except in the case of an implicit interface function, where
you could use the optional attribute on the type specification
statement).
P.S. One other case where you have to write an interface body is for
calling non-Fortran procedures. For me, that's far more common than
having procedure dummy arguments.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
arjenmarkus
Jun 1, 2012, 3:02:31 AM6/1/12
to
On 2012-05-31 17:56, Richard Maine wrote:
>> I do not know if it is possible - checking for the presence or absence
>> seems odd too
>
> I don't know what is so odd about it. Argument presence is orthogonal to
> any matter if the argument being a data argument. Anyway, yes, that's
> perfectly fine.
>
I was thinking of the idiom:
>> I do not know if it is possible - checking for the presence or absence
>> seems odd too
>
> I don't know what is so odd about it. Argument presence is orthogonal to
> any matter if the argument being a data argument. Anyway, yes, that's
> perfectly fine.
>
if ( present(f) ) then
f_local = f
else
f_local = f_default
endif
For procedures under F95 that can not be done. Under F2003 it
would be:
f_local => f
But as F2003 is not an option for OP, that is not a solution.
Regards,
Arjen
Phillip Helbig---undress to reply
Jun 1, 2012, 4:40:18 AM6/1/12
to
In article <h3Kxr.7512$v14....@viwinnwfe02.internal.bigpond.com>, Ian
Fortran 95.
Harvey <ian_h...@bigpond.com> writes:
> > Is there a way to do this without explicitly writing the interface?
>
> Not in F95 as far as I am aware.
>
> In F2003 you could use a minor variant on the abstract interface
> approach that Wolfgang posted upthread.
>
> module foo
> implicit none
> contains
> real function f(x)
> real :: x
> ...
> end function f
>
> subroutine apply_f(f_arg)
> procedure(f), optional :: f_arg ! #1
> ...
> end subroutine apply_f
> end module foo
>
> The procedure statement at #1 says that the interface of the dummy
> argument f_arg has the same characteristics as the interface of the
> module procedure f.
This is exactly what I need. Alas, as you mention, not possible in
> > Is there a way to do this without explicitly writing the interface?
>
> Not in F95 as far as I am aware.
>
> In F2003 you could use a minor variant on the abstract interface
> approach that Wolfgang posted upthread.
>
> module foo
> implicit none
> contains
> real function f(x)
> real :: x
> ...
> end function f
>
> subroutine apply_f(f_arg)
> procedure(f), optional :: f_arg ! #1
> ...
> end subroutine apply_f
> end module foo
>
> The procedure statement at #1 says that the interface of the dummy
> argument f_arg has the same characteristics as the interface of the
> module procedure f.
Fortran 95.
Phillip Helbig---undress to reply
Jun 1, 2012, 4:48:16 AM6/1/12
to
In article <jq9pe7$421$1...@dont-email.me>, arjenmarkus
interface
function f(x)
else if (present (z) ) then
y = z
else
print*, "either f or z must be specified"
endif
<arjen.m...@gmail.com> writes:
> I was thinking of the idiom:
>
> if ( present(f) ) then
> f_local = f
> else
> f_local = f_default
> endif
I was thinking of:
> I was thinking of the idiom:
>
> if ( present(f) ) then
> f_local = f
> else
> f_local = f_default
> endif
interface
function f(x)
real :: x
real :: f
end function f
end interface
optional :: f
real, optional :: z
real :: f
end function f
end interface
optional :: f
if ( present(f) ) then
y = f(x)
else if (present (z) ) then
y = z
else
print*, "either f or z must be specified"
endif
arjenmarkus
Jun 1, 2012, 5:35:11 AM6/1/12
to
you want to do with the optional argument. If the procedure
has to be used in various locations, then it pays off to
create a default procedure.
Regards,
Arjen
Richard Maine
Jun 1, 2012, 11:54:36 AM6/1/12
to
anything much relating to that. Seems to me like you are looking for a
solution to a question not asked. It asked about optional procedure
arguments. Just because there is something optional doesn't mean that
you have to provide a local default. It is a common idiom, but certainly
not the only way to use optional arguments.
What f95 doesn't have is anything much like procedure variables except
for the limitted case of dummy arguments, which aren't called variables,
but are sort of like them. The lack of procedure variables is why you
can't do your example in f95. F2003 procedure pointers play a role like
procedure variables. (In fact, there was a bit of debate during
development as to whether to make them called variables or pointers; I
forget the details of the debate, though I vaguely recall being on the
other side of it at the time).
So the functionality of these sort-of-variable-like dummy arguments is
limitted in many ways in f95. But those limitations are not particularly
related to being optional. For example, you can't have an intent(out)
procedure argument. You can, however, have an optional procedure
argument.
glen herrmannsfeldt
Jun 1, 2012, 1:57:44 PM6/1/12
to
Richard Maine <nos...@see.signature> wrote:
(snip, someone wrote)
a function or ordinary variable. That, as far as I know, can't
be done in any version of the standard.
> What f95 doesn't have is anything much like procedure variables except
> for the limitted case of dummy arguments, which aren't called variables,
> but are sort of like them. The lack of procedure variables is why you
> can't do your example in f95. F2003 procedure pointers play a role like
> procedure variables. (In fact, there was a bit of debate during
> development as to whether to make them called variables or pointers; I
> forget the details of the debate, though I vaguely recall being on the
> other side of it at the time).
What to call them seems always to be a problem. PL/I calls them
ENTRY variables. That gets confusing, as ENTRY is also how you
declare external procedures (which can be the main entry point,
or an ENTRY statement). That is, similar to C function prototypes.
In C, they are usually called function pointers, and in most
implmentations store the address of a function. To continue
the confusion, do you need to dereference one with * or not?
> So the functionality of these sort-of-variable-like dummy
> arguments is limitted in many ways in f95. But those limitations
> are not particularly related to being optional. For example,
> you can't have an intent(out) procedure argument. You can,
> however, have an optional procedure argument.
Back to at least Fortran 66, and I believe to Fortran II.
-- glen
(snip, someone wrote)
>> For procedures under F95 that can not be done. Under F2003 it
>> would be:
>> f_local => f
>> But as F2003 is not an option for OP, that is not a solution.
> Sure that can't be done, but I don't see where the original post asked
> anything much relating to that. Seems to me like you are looking for a
> solution to a question not asked. It asked about optional procedure
> arguments. Just because there is something optional doesn't mean that
> you have to provide a local default. It is a common idiom, but certainly
> not the only way to use optional arguments.
At some point, I thought the OP wanted an argument that was either
>> would be:
>> f_local => f
>> But as F2003 is not an option for OP, that is not a solution.
> Sure that can't be done, but I don't see where the original post asked
> anything much relating to that. Seems to me like you are looking for a
> solution to a question not asked. It asked about optional procedure
> arguments. Just because there is something optional doesn't mean that
> you have to provide a local default. It is a common idiom, but certainly
> not the only way to use optional arguments.
a function or ordinary variable. That, as far as I know, can't
be done in any version of the standard.
> What f95 doesn't have is anything much like procedure variables except
> for the limitted case of dummy arguments, which aren't called variables,
> but are sort of like them. The lack of procedure variables is why you
> can't do your example in f95. F2003 procedure pointers play a role like
> procedure variables. (In fact, there was a bit of debate during
> development as to whether to make them called variables or pointers; I
> forget the details of the debate, though I vaguely recall being on the
> other side of it at the time).
ENTRY variables. That gets confusing, as ENTRY is also how you
declare external procedures (which can be the main entry point,
or an ENTRY statement). That is, similar to C function prototypes.
In C, they are usually called function pointers, and in most
implmentations store the address of a function. To continue
the confusion, do you need to dereference one with * or not?
> So the functionality of these sort-of-variable-like dummy
> arguments is limitted in many ways in f95. But those limitations
> are not particularly related to being optional. For example,
> you can't have an intent(out) procedure argument. You can,
> however, have an optional procedure argument.
-- glen
Gordon Sande
Jun 1, 2012, 2:37:52 PM6/1/12
to
procedure assigments by arguement association. That translates
into have a wrapper routine which makes one of two calls based
on the present status.
This gets messy if there are multiple option arguements. The
assumption is that the OP wanted to do the fiddly bits at the
beginning and not be bothered later by whether the function
used ase passed or default. The use of wrappers to tame arguement
lists is an old technique that is less required with the support
of optional arguemetns in the language. This seems to be a plausibe
use to work around the need for procedure variables and the desire
to stick with F95.
Phillip Helbig---undress to reply
Jun 2, 2012, 5:34:48 AM6/2/12
to
In article <1kl05dl.1shynco1xfuio0N%nos...@see.signature>,
the calling program has two options: pass a variable name, the value of
which will be used by the called routine, or pass a procedure name, in
which case the value will be calculated by the procedure. In my example
of calculating the time to fly somewhere, in the first case the variable
would be a constant wind speed (well, maybe speed and direction) while
in the second case the wind will be calculated as a function of time and
place. The idea is not to replace a default procedure with a
user-defined procedure, but rather to replace a simple solution with a
more involved solution. (Actually, the procedure can be either user
written or the user can specify a routine which is part of the module
with all the other routines. Since the value is used very often, it is
good to avoid the overhead of procedure calls unless they are needed.
One could, of course, have a procedure which always returns the same
value, but that is the overhead I want to avoid.)
nos...@see.signature (Richard Maine) writes:
> Sure that can't be done, but I don't see where the original post asked
> anything much relating to that. Seems to me like you are looking for a
> solution to a question not asked. It asked about optional procedure
> arguments. Just because there is something optional doesn't mean that
> you have to provide a local default. It is a common idiom, but certainly
> not the only way to use optional arguments.
Right. In my case, there is no local default routine. The idea is that
> Sure that can't be done, but I don't see where the original post asked
> anything much relating to that. Seems to me like you are looking for a
> solution to a question not asked. It asked about optional procedure
> arguments. Just because there is something optional doesn't mean that
> you have to provide a local default. It is a common idiom, but certainly
> not the only way to use optional arguments.
the calling program has two options: pass a variable name, the value of
which will be used by the called routine, or pass a procedure name, in
which case the value will be calculated by the procedure. In my example
of calculating the time to fly somewhere, in the first case the variable
would be a constant wind speed (well, maybe speed and direction) while
in the second case the wind will be calculated as a function of time and
place. The idea is not to replace a default procedure with a
user-defined procedure, but rather to replace a simple solution with a
more involved solution. (Actually, the procedure can be either user
written or the user can specify a routine which is part of the module
with all the other routines. Since the value is used very often, it is
good to avoid the overhead of procedure calls unless they are needed.
One could, of course, have a procedure which always returns the same
value, but that is the overhead I want to avoid.)
Phillip Helbig---undress to reply
Jun 2, 2012, 5:41:50 AM6/2/12
to
In article <jqavqo$it3$1...@speranza.aioe.org>, glen herrmannsfeldt
and the procedure are OPTIONAL, and an error occurs if neither is
specified. (Actually, there are two variables (one integer and one
real) and one procedure, all optional, and exactly one must be
specified.)
This is not some contrived example; it is real code. I want to make it
conceptually very clear so that it is easy for other people to use. One
part of it is some code I wrote a bit more than 15 years ago, in F77. I
have rewritten it in F95 and it will be part of a much larger package.
The original code was used in the Perlmutter et al. paper for which the
2011 Nobel Prize in physics was awarded, so I know that other people use
my code and I want to make sure it is as good as possible. :-)
> > So the functionality of these sort-of-variable-like dummy
> > arguments is limitted in many ways in f95. But those limitations
> > are not particularly related to being optional. For example,
> > you can't have an intent(out) procedure argument. You can,
> > however, have an optional procedure argument.
>
> Back to at least Fortran 66, and I believe to Fortran II.
Procedure arguments were there in F77 (I haven't used any older
Fortran). But OPTIONAL procedure arguments? OPTIONAL wasn't introduced
until F90.
<g...@ugcs.caltech.edu> writes:
> Richard Maine <nos...@see.signature> wrote:
>
> (snip, someone wrote)
> >> For procedures under F95 that can not be done. Under F2003 it
> >> would be:
>
> >> f_local => f
>
> >> But as F2003 is not an option for OP, that is not a solution.
>
> > Sure that can't be done, but I don't see where the original post asked
> > anything much relating to that. Seems to me like you are looking for a
> > solution to a question not asked. It asked about optional procedure
> > arguments. Just because there is something optional doesn't mean that
> > you have to provide a local default. It is a common idiom, but certainly
> > not the only way to use optional arguments.
>
> At some point, I thought the OP wanted an argument that was either
> a function or ordinary variable. That, as far as I know, can't
> be done in any version of the standard.
Right. But I know that that can't be done. :-) So, both the variable
> Richard Maine <nos...@see.signature> wrote:
>
> (snip, someone wrote)
> >> For procedures under F95 that can not be done. Under F2003 it
> >> would be:
>
> >> f_local => f
>
> >> But as F2003 is not an option for OP, that is not a solution.
>
> > Sure that can't be done, but I don't see where the original post asked
> > anything much relating to that. Seems to me like you are looking for a
> > solution to a question not asked. It asked about optional procedure
> > arguments. Just because there is something optional doesn't mean that
> > you have to provide a local default. It is a common idiom, but certainly
> > not the only way to use optional arguments.
>
> At some point, I thought the OP wanted an argument that was either
> a function or ordinary variable. That, as far as I know, can't
> be done in any version of the standard.
and the procedure are OPTIONAL, and an error occurs if neither is
specified. (Actually, there are two variables (one integer and one
real) and one procedure, all optional, and exactly one must be
specified.)
This is not some contrived example; it is real code. I want to make it
conceptually very clear so that it is easy for other people to use. One
part of it is some code I wrote a bit more than 15 years ago, in F77. I
have rewritten it in F95 and it will be part of a much larger package.
The original code was used in the Perlmutter et al. paper for which the
2011 Nobel Prize in physics was awarded, so I know that other people use
my code and I want to make sure it is as good as possible. :-)
> > So the functionality of these sort-of-variable-like dummy
> > arguments is limitted in many ways in f95. But those limitations
> > are not particularly related to being optional. For example,
> > you can't have an intent(out) procedure argument. You can,
> > however, have an optional procedure argument.
>
> Back to at least Fortran 66, and I believe to Fortran II.
Fortran). But OPTIONAL procedure arguments? OPTIONAL wasn't introduced
until F90.
0 new messages