re: fortran extensions

[Steven_L_Intel1]

We do not intend to drop any CVF extensions as it turns into Intel Visual Fortran.

As for pointers to procedures, you can do this in CVF:

external myproc
pointer (p_myproc,myproc)
p_myproc = some_address
call myproc (arg1,arg2,arg3)

This also works for function references. I'm not sure what, if anything, Fortran 2000 (2004?) has in this area.

Steve

[Jugoslav_Dujic]

Uhh... If I were you, I'd consider redesign ;-).

OK, answers first:

> 1. did you mean "call p_myproc(arg1...)" in your
> example?
> as I understand p_myproc is the pointer to an
> external procedure myproc (the pointee).

No - you can't call a pointer, but only a pointee (myproc)

> 2. can myproc be a procedure name passed as a dummy
> argument with an explicit interface?

EXTERNAL and INTERFACE have more or less the same semantics; the latter allows you finer control, of course.
Declaration EXTERNAL Myproc;POINTER(p_Myproc, Myproc) in Steve's sample declares an external that exists "in vain".
Myproc will begin associated with something real when p_Myproc is assigned a value. p_MyProc=some_address means

myproc => SomeAddress

But of course it's not allowed in standard F95.
Since Myproc is a "non-existing" routine, it can't be a dummy argument (argProc). However, you can take LOC(argProc) and assign it to p_Myproc (which, effectively, causes that argProc and MyProc become synonyms for a same thing).

> 3. can p_myproc be a module-level variable - that is,
> not local to a subroutine? in that case, how could I
> declare the Cray pointer in the module?

Cray pointers to routines are useful in, e.g.:
- Dynamic binding of DLL routines
- Creating function tables in general-purpose libraries.

Yes, you can have them in modules. See for example my recent MAPI.f90 header (MAPIBind() routine is used to bind crays to real addresses)

> The reason I need pointers to functions is to give a
> (quite complicated) module procedure proc1 access to
> a dummy argument dumproc of another (even more
> complex) module procedure proc2. The trick is that
> proc1 is itself provided as an argument to routine
> proc2 and proc2 knows nothing about the argument list
> of dumproc (or that it even exists), and also dumproc
> needs access to some dummy variables of proc1
> (confusing enough?). The strict F-95 implementation
> is quite restrictive, but allowing internal
> procedures to be passed as arguments makes this
> problem trivial. Function pointers could also be used
> to solve this problem, but I did not realise they are
> allowed in CVF.

But, to repeat, I'd really consider redesign. F95 is restrictive just in order not to provide guns to kids ;-).

Jugoslav