Re: type/rank mismatch error

On Jun 29, 9:14 am, "Les" <l.neil...@xxxxxxxxxxxxxxxxxxx> wrote:
<estev...@xxxxxxxxx> wrote in message

news:1183130878.777871.123690@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



Richard, Jugoslav,

Thank you both for clarifying the issue, which was one of scope and a
namespace confusion. My previous post was perhaps not clear --
probably as opaque as this code. As before, the module is

<snip>

After your informative posts, I reread the scoping rules (surprise,
noob F90 programmer). I realized that the external driver would make
a call to number1 like this:

PROGRAM driver
USE calculate <-------- this USE allows the driver
to use the subroutine in module calculate
USE various <-------- contains subroutines that
do dirty work
! variables...
call number1(aa,bb,some_op) <-------- here I can address the
name of the subroutine directly
...
END PROGRAM

Inside MODULE various, both the SUBROUTINE declarations, AND any
subsequent nested subroutine calls that also need 'some_op' inside
must have a different name for their dummies, with an appropriate
EXTERNAL declaration for those dummy args. So, the original module
various should look more like

MODULE various
USE calculate
CONTAINS
SUBROUTINE number1(x1,y1,op1)
EXTERNAL :: op1
REAL :: x1,y1
... other calcs
call number2(x1,y1,op1)
END SUBROUTINE number1
!
SUBROUTINE number2(x2,y2,op2)
EXTERNAL :: op2
call number3(x2,y2,op2)
END SUBROUTINE number2
...
END MODULE various

This way, there isn't confusion about the naming of the module.

However, this seems to me an obfuscated way of coding. Is there some
way to name the subroutine some_op consistently?

Thanks for your help and expertise!

If you are _always_ going to eventually call "some_op" then there is no need
to pass it to the various "number" routines - just do a call some_op at the
appropriate place, providing you have the appropriate "USE calculate" giving
you access to the some_op subroutine (which you do have in the code you
showed).

But if the "number" routines are to be general purpose then *any*
appropriate routine can be passed, from the caller, as the actual argument
to op1, op2 etc, along with *any* appropriate values/variables for the other
arguments. In fact you could replace op1, op2 etc with just op in each of
the number routines indicating that each expects an external routine of some
sort.

Les

Thanks Les! In this case, passing the subroutine is really not
necessary. Your comment turned the light bulb on in my head!

Thanks everyone for their help!

.

Relevant Pages

  • Re: Fast pancake flipping
    ... excerpt of my fast flipper here. ... Recently I wrote a subroutine that seemed to qualify for the ... It is certainly true that making a routine readable is usually ...
    (comp.programming)
  • Re: What routine is running
    ... argumnent a dynamic array and, with the addition of 1 line of code in the ... sub, gurarantee the existing code will work. ... duplicating an entire routine is a terrible solution. ... if the subroutine is meant to modify the value ...
    (comp.databases.pick)
  • Re: Are these the same arguments?
    ... to do those optimizations. ... routine is using it as an array, ... routine is using the argument as an array. ... subroutine sub1([other args], x) ...
    (comp.lang.fortran)
  • Re: using optional arguments not present (bug)
    ... an attribute for an optional dummy argument that makes the dummy ... end subroutine sub ... actual argument to sub2 is always present; it doesn't get a non-present ... E.g. nearly all my procedures have an optional argument "message_log" which is passed to a message display routine. ...
    (comp.lang.fortran)
  • Using forms?
    ... I made a subroutine that calls the form with a show ... routine working now but I noticed that by default it is public. ... How can I get the remote query to complete without releasing the form? ... How can I return a value from the form to the calling program? ...
    (microsoft.public.excel.programming)