Any suggested workarounds for writing wrappers for functions that areto be passed as arguments?

The easy solution to this problem is to pass an internal function as
an argument, but of course that is not allowed in standard-conforming
Fortran 90+. What I mean by "internal function" is a function which
is CONTAINed by another function (or subroutine). Now just a little
more specific info so you can feel out the situation.

So what do I want to do?
------------------------------------
Say I want to create a module of integration routines in xy Cartesian
geometry for integrating a user-specified function, f(x,y) over a
polygon. Easy enough.

How do I want to do it?
---------------------------------
I want to use as many integration routines as I can find (e.g. in TOMS/
ACM/textbooks/etc) There is some great stuff out there, written in F77
especially. The difficulty comes in providing a "standardized"
interface to the various integration routines I have collected. I
don't want to go in and rewrite all those routines to accept f(x,y).
I want to write for each method a "wrapper function" of the form
(where ABC specifies some specific method--e.g. trapezoid rule):

FUNCTION Integrate_ABC( f , N , Pg , reltol ) RESULT(val)

!! 1. interface for function argument
INTERFACE
REAL FUNCTION f(x,y)
REAL :: x,y
END FUNCTION
END INTERFACE

!! 2. polygon definition
INTEGER,INTENT(IN) :: N
REAL,INTENT(IN) :: Pg(2,N)

!! 3. tolerance for end result
REAL,INTENT(IN),OPTIONAL :: reltol

!! 4. output
REAL :: val

!!--begin--

some setup stuff

!call someone else's routine with all the right arguments, including
local version of the function f (flocal)
CALL integABC( flocal , ... )

some wrapup stuff, i.e. set return value, val=something

!!--end--
END FUNCTION

If you noticed "flocal" as the first argument to "integABC" then you
are with me. "integABC" is not expecting a function of the form
f(x,y), but maybe something like this:

REAL FUNCTION flocal( r )
REAL,INTENT(IN) :: r(2)
!!--begin--
flocal = f( r(1) , r(2) )
!!--end--
END FUNCTION

But of course now function flocal must know about function f---without
f being passed as an argument to flocal because then flocal won't have
the right interface, flocal(r,f) instead of flocal(r) like "integABC"
expects. The only way I know that this can be done is for flocal to be
CONTAINed in wrapper Integrate_ABC, which means that it cannot then be
passed as an argument!

Side question
--------------------
Is there any possibility the ability to pass an internal function as
an argument is going to be added to the standard?

Main question
---------------------
Can anyone think of a way to provide such a collection of wrappers
like the example Integrate_ABC above for integABC?


Best Regards,
Will

An intriguing question .

I have not worked this out in any detail, but a half-forgotten
feature of FORTRAN 77 is the ENTRY statement. Basically, it defines
a facility that one would now probably use internal functions for,
but it might actually help here.

Something along these lines:

real function integrate_abc( f, n, pg, reltol )
... appropriate declarations

... preparation
call integabc( flocal, ... )
... completion
return

!
! Here it comes
!
entry flocal( pg )

flocal = f(pg)

end function

I have never much used the ENTRY statement, so I may have the
details completely wrong but it seems it can solve your problem.

Best way though is to experiment with it (an ENTRY acts
as a function of the same type in this case; if integrate_abc
were a subroutine, it would be a subroutine).

A better (clearer, more modern) way would be to use function
pointers, as is possible with Fortran 2003.

Regards,

Arjen

On 2 sep, 13:53, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> An intriguing question .
>
> I have not worked this out in any detail, but a half-forgotten
> feature of FORTRAN 77 is the ENTRY statement. Basically, it defines
> a facility that one would now probably use internal functions for,
> but it might actually help here.
>
> Something along these lines:
>
> real function integrate_abc( f, n, pg, reltol )
> * * ... appropriate declarations
>
> * * ... preparation
> * * call integabc( flocal, ... )
> * * ... completion
> * * return
>
> !
> ! Here it comes
> !
> entry flocal( pg )
>
> * *flocal = f(pg)
>
> end function
>
> I have never much used the ENTRY statement, so I may have the
> details completely wrong but it seems it can solve your problem.
>
> Best way though is to experiment with it (an ENTRY acts
> as a function of the same type in this case; if integrate_abc
> were a subroutine, it would be a subroutine).
>
> A better (clearer, more modern) way would be to use function
> pointers, as is possible with Fortran 2003.
>
> Regards,
>
> Arjen

Experimenting with something like brought out internal errors
in two compilers and a third is giving error messages that
I can not explain.

Probably a rather obscure corner of the Fortran language

Regards,

Arjen

On Sep 2, 10:01*am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> On 2 sep, 13:53, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>
>
>
> > An intriguing question .
>
> > I have not worked this out in any detail, but a half-forgotten
> > feature of FORTRAN 77 is the ENTRY statement. Basically, it defines
> > a facility that one would now probably use internal functions for,
> > but it might actually help here.
>
> > Something along these lines:
>
> > real function integrate_abc( f, n, pg, reltol )
> > * * ... appropriate declarations
>
> > * * ... preparation
> > * * call integabc( flocal, ... )
> > * * ... completion
> > * * return
>
> > !
> > ! Here it comes
> > !
> > entry flocal( pg )
>
> > * *flocal = f(pg)
>
> > end function
>
> > I have never much used the ENTRY statement, so I may have the
> > details completely wrong but it seems it can solve your problem.
>
> > Best way though is to experiment with it (an ENTRY acts
> > as a function of the same type in this case; if integrate_abc
> > were a subroutine, it would be a subroutine).
>
> > A better (clearer, more modern) way would be to use function
> > pointers, as is possible with Fortran 2003.
>
> > Regards,
>
> > Arjen
>
> Experimenting with something like brought out internal errors
> in two compilers and a third is giving error messages that
> I can not explain.
>
> Probably a rather obscure corner of the Fortran language
>
> Regards,
>
> Arjen

Well thanks for looking into it. I never knew what ENTRY was for. Do
you know of any compilers that have implemented F03's function
pointers?

+W

On Mon, 1 Sep 2008 21:02:59 -0700 (PDT), "Will W."
<william.wieselquist@gmail.com> wrote:

>Side question
>--------------------
>Is there any possibility the ability to pass an internal function as
>an argument is going to be added to the standard?

This is in the current draft for Fortran 2008. Some compilers (e.g. Intel
Fortran) already support this.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/per...etools/fortran
My Fortran blog
http://www.intel.com/software/drfortran

On Tue, 2 Sep 2008 04:53:56 -0700 (PDT), Arjen Markus
<arjen.markus@wldelft.nl> wrote:

>real function integrate_abc( f, n, pg, reltol )
> ... appropriate declarations
>
> ... preparation
> call integabc( flocal, ... )
> ... completion
> return
>
>!
>! Here it comes
>!
>entry flocal( pg )
>
> flocal = f(pg)
>
>end function

This is illegal - when entered through flocal, dummy argument f is not allowed
to be referenced since it is not in the dummy argument list of flocal.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/per...etools/fortran
My Fortran blog
http://www.intel.com/software/drfortran

Steve Lionel wrote:
> On Tue, 2 Sep 2008 04:53:56 -0700 (PDT), Arjen Markus
> <arjen.markus@wldelft.nl> wrote:
>
>> real function integrate_abc( f, n, pg, reltol )
>> ... appropriate declarations
>>
>> ... preparation
>> call integabc( flocal, ... )
>> ... completion
>> return
>>
>> !
>> ! Here it comes
>> !
>> entry flocal( pg )
>>
>> flocal = f(pg)
>>
>> end function
>
> This is illegal - when entered through flocal, dummy argument f is not allowed
> to be referenced since it is not in the dummy argument list of flocal.

It's also recursive. The function needs the RECURSIVE specifier.

Dick Hendrickson
> --
> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH
>
> For email address, replace "invalid" with "com"
>
> User communities for Intel Software Development Products
> http://softwareforums.intel.com/
> Intel Fortran Support
> http://support.intel.com/support/per...etools/fortran
> My Fortran blog
> http://www.intel.com/software/drfortran

On Sep 2, 10:23*am, Steve Lionel <Steve.Lio...@intel.invalid> wrote:
> On Mon, 1 Sep 2008 21:02:59 -0700 (PDT), "Will W."
>
> <william.wieselqu...@gmail.com> wrote:
> >Side question
> >--------------------
> >Is there any possibility the ability to pass an internal function as
> >an argument is going to be added to the standard?
>
> This is in the current draft for Fortran 2008. *Some compilers (e.g. Intel
> Fortran) already support this.
GREAT. Do you happen to know as of which version it is supported for
Intel? We have 9.1 on our linux cluster and I would like to be able
to use it there. Thanks,
+W

"Will W." <william.wieselquist@gmail.com> wrote in message
news:563f03fb-e1a2-4151-9686-b47b50fb39fb@56g2000hsm.googlegroups.com...

> On Sep 2, 10:23 am, Steve Lionel <Steve.Lio...@intel.invalid> wrote:
> > On Mon, 1 Sep 2008 21:02:59 -0700 (PDT), "Will W."

> > <william.wieselqu...@gmail.com> wrote:
> > >Side question
> > >--------------------
> > >Is there any possibility the ability to pass an internal function as
> > >an argument is going to be added to the standard?

> > This is in the current draft for Fortran 2008. Some compilers (e.g.
> > Intel
> > Fortran) already support this.

> GREAT. Do you happen to know as of which version it is supported for
> Intel? We have 9.1 on our linux cluster and I would like to be able
> to use it there. Thanks,

Since approximately DVF.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Dick Hendrickson <dick.hendrickson@att.net> wrote:

> Steve Lionel wrote:
> > On Tue, 2 Sep 2008 04:53:56 -0700 (PDT), Arjen Markus
> > <arjen.markus@wldelft.nl> wrote:
....
> >> entry flocal( pg )

> > This is illegal - when entered through flocal, dummy argument f is not
> > allowed to be referenced since it is not in the dummy argument list of
> > flocal.
>
> It's also recursive. The function needs the RECURSIVE specifier.

Entry has a large number of "quirks" and special cases. At one time it
was on a list of features to be declared obsolescent. I don't recall
whether that survived the development process to date, but in any case,
I would not personally recommend using ENTRY for anything in new code. A
module provides a better way of doing most of this style of thing (where
two procedures share some of the same data).

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain