From hirchert@ncsa.uiuc.edu Tue Mar 28 05:57:21 1995
Received: from newton.ncsa.uiuc.edu by dkuug.dk with SMTP id AA29830
  (5.65c8/IDA-1.4.4j for <SC22WG5@dkuug.dk>); Tue, 28 Mar 1995 20:08:22 +0200
Received: from landrew.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA03046
  (5.65a/IDA-1.4.2 for SC22WG5@dkuug.dk); Tue, 28 Mar 95 12:04:47 -0600
Return-Path: <hirchert@ncsa.uiuc.edu>
Received: by landrew.ncsa.uiuc.edu (4.1/NCSA-4.1)
	id AA03660; Tue, 28 Mar 95 11:57:26 CST
Message-Id: <9503281757.AA03660@landrew.ncsa.uiuc.edu>
From: hirchert@ncsa.uiuc.edu (Kurt W. Hirchert)
Date: Tue, 28 Mar 1995 11:57:21 -0600
In-Reply-To: Lawrie Schonfelder's message of Mar 28, 14:28
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Lawrie Schonfelder <J.L.Schonfelder@liverpool.ac.uk>,
        "John.Reid" <John.Reid@maths.anu.edu.au>
Subject: Re: (SC22WG5.774) Re: Pointers to procedures
Cc: comp-fortran-90@mailbase.ac.uk, SC22WG5@dkuug.dk
X-Charset: ASCII
X-Char-Esc: 29

On Tue, Mar 28, 1995, at 14:28, Lawrie Schonfelder wrote:
>On Tue, 28 Mar 1995 17:56:39 +1000 John.Reid wrote:
>> I gave a talk on Fortran 90 here at ANU, which has provoked a finite-element
>> expert to ask why we do not have pointers to procedures in Fortran 90. 
>
>As usual I think the call for pointers to procedures is really a request for 
>procedure variables and I think if we are going to have mutilevel indirection 
>such as pointers I think we should have the single level provided by variables 
>as well or first. 
>-- End of except from Lawrie Schonfelder (J.L.Schonfelder@liverpool.ac.uk)

I suspect you are separated more by choice of words than semantics.  What some
languages (e.g., PL/I) call procedure variables, other languages (e.g., C)
call procedure pointers.  What is being requested is a means to reference
procedures whose identity is specified indirectly.  I suspect that few if
any of the requestors care whether the notation used is that of variables or
that of pointers.

[Personally, I have a preference (but not a requirement) for calling them
pointers.  At the implementation level, what is being stored is the address
of the procedure code, not the procedure code itself.  At the notational
level, the restrictions on what may appear on the RHS of an indirect
procedure "assignement" is more like the restrictions on pointer assignment
than like ordinary variable assignment.]

I agree with Lawrie that allowing this only inside a derived type would be
an irregularity.  In order to allow it outside derived types, there needs
to be some kind of explicit declaration of the indirection.

[If we call these pointers to procedures, then the POINTER attribute could
be that declaration.  E.g.
      POINTER :: P
      EXTERNAL :: P
could be the declaration of a procedure pointer with an implicit interface
(if we allow such things) and the combination of POINTER and an interface
block could be the declaration of a procedure pointer with an explicit
interface.  It might also be nice to have a "combined" notation:
      POINTER,EXTERNAL :: P

      INTERFACE
        POINTER,SUBROUTINE PS(SOMEARG) ! Is this the right syntax?
        END SUBROUTINE
        POINTER ::    ! Or should it be something like this?
        FUNCTION PF(OTHERARG)
        END FUNCTION
      END INTERFACE
Of course, if we really like procedure variables better, we could add a
new VARIABLE keyword and use it in an analogous manner.]

On most of the rest of Lawrie's questions, I would suggest that we recognize
that we already have one form of indirectly specified procedures in dummy
procedures and that the answers for this new form should be the same as the
existing answers for dummy procedures.  Thus, procedure "pointers" identify
specific procedures, but if those procedures have explicit interfaces they
can be included in a generic interface specification; when accessing a
procedure through a procedure "pointer", keyword arguments are specified
using those declared for the "pointer", not those specified for the "pointee";
etc.

(In case it isn't obvious, my answer to John Reid's question is that I
think this is a very desirable feature.  It's probably too large to add
in response to F95 public comment, so presumably it will have to wait for
F2K.)

-- 
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications