Hello,

I need help understanding the "contains" statement. In particular, why I 
cannot have two contains statements in a program:


program test
     write (*,*) "Life"
     contains

     subroutine foo
         write (*,*) "Universe ", bar()

         contains

         function bar()
             real :: bar

             bar = 42.0
         end function
     end subroutine
end program


Apparently I can't have two contains statements, I thought you could use 
the contains statement to avoid using global variables.


I have a program that I want to keep from getting too complicated. I 
have a subroutine that has to do an N-body simulation with massive 
particles. There are a couple of functions that need to know that 
positions of those particles, but only a couple. I don't want to have 
all that information in a global variable. So my plan was to do 
something like this:


program myprogram
     ...
     contains

     subroutine mysimulation
         real :: particles(...)
         ...
         contains

         function force_calculation()
             ...
             ! This function can access 'particles'.
             ...
         end function
     end subroutine
end program


I thought that the "contains" statement would take care of this, but 
apparently it doesn't.

Help?

Daniel.

On 28/11/11 12:07, Daniel Carrera wrote:
> Hello,
>
> I need help understanding the "contains" statement. In particular, why I
> cannot have two contains statements in a program:
>
>
> program test
> write (*,*) "Life"
> contains
>
> subroutine foo
> write (*,*) "Universe ", bar()
>
> contains
>
> function bar()
> real :: bar
>
> bar = 42.0
> end function
> end subroutine
> end program
>
>
> Apparently I can't have two contains statements, I thought you could use
> the contains statement to avoid using global variables.
>
>
> I have a program that I want to keep from getting too complicated. I
> have a subroutine that has to do an N-body simulation with massive
> particles. There are a couple of functions that need to know that
> positions of those particles, but only a couple. I don't want to have
> all that information in a global variable...

Internal subprograms (which define internal procedures) can't have 
internal subprograms.

An internal subprogram is something that appears after the contains 
statement in a main program unit (as you have in your example) or an 
external subprogram (a function program unit or subroutine program 
unit).  Note that when I say function or subroutine program unit here 
that I am talking about the "top level" units of a program.

(Writing external subprograms in modern Fortran source should only be 
required in particular situations - where possible functions and 
subroutines that are module subprograms (they give rise to module 
procedures) should be written instead.)

On the other hand, module subprograms can have internal subprograms.  A 
module subprogram is something that appears after the contains statement 
in a module.

So this is ok:

MODULE a_module
   IMPLICIT NONE
CONTAINS
   SUBROUTINE a_module_subprogram
   CONTAINS
     SUBROUTINE an_internal_subprogram
     END SUBROUTINE an_internal_subprogram
   END SUBROUTINE a_module_subprogram
END MODULE a_module

But this is not:

SUBROUTINE an_external_subprogram
   IMPLICIT NONE
CONTAINS
   SUBROUTINE an_internal_subprogram
   CONTAINS
     SUBROUTINE something_that_is_not_allowed
     END SUBROUTINE something_that_is_not_allowed
   END SUBROUTINE an_internal_subprogram
END SUBROUTINE an_external_subprogram

In terms of your situation - perhaps you need to think about separating 
out some of the bits of your main program into a module or two.  While 
this might increase the complexity of your source code slightly, it will 
assist if in future if you ever need to re-use the split-out bits in a 
different main program.

On 11/28/2011 02:59 AM, Ian Harvey wrote:
> On 28/11/11 12:07, Daniel Carrera wrote:
>> Hello,
>>
>> I need help understanding the "contains" statement. In particular, why I
>> cannot have two contains statements in a program:
>> [...]

The very first error that I made once I saw bits from Fortran 90, was to 
write something like

module foo
!...
contains
   module bar
     !...
   end module
end module

Although this doesn't make sense, I still think module nesting would be 
a natural concept.  However, the submodules that made it into the newest 
standard are a completely different (and probably more useful) concept.

Nevertheless, there are currently five levels of nesting via CONTAINS 
allowed if I didn't miss one:

module a
contains
   subroutine b
   contains
     subroutine c
       type :: d
       contains
         procedure :: e
       end type d
     end subroutine c
   end subroutine b
end module a


-- Wolfgang

-- 
E-mail: firstnameinitial.lastname@domain.de
Domain: yahoo

On 11/28/2011 08:37 AM, Wolfgang Kilian wrote:
> On 11/28/2011 02:59 AM, Ian Harvey wrote:
>> On 28/11/11 12:07, Daniel Carrera wrote:
>>> I need help understanding the "contains" statement. In particular, why I
>>> cannot have two contains statements in a program:

I don't know why you cannot have another layer of internal procedures 
within an internal procedure, but the Fortran standard does not allow it.

However, you can "nest" the "contains" statements in modules: The first 
"contains" tells you that now the module procedures come and within a 
module procedure, you can have internal procedures.
(If you count type-bound procedures, you can have yet another layer with 
"contains", as Wolfgang showed.)

For your problem: Generate a module, stuff in all of the procedures 
which were previously "contained" in the main program. Then you can also 
use an internal procedure. I think in nearly all cases, splitting off 
the declaration into a module removes the need to nest procedures within 
internal procedures.

Tobias

Thanks.

On 11/28/2011 08:47 AM, Tobias Burnus wrote:
> On 11/28/2011 08:37 AM, Wolfgang Kilian wrote:
>> On 11/28/2011 02:59 AM, Ian Harvey wrote:
>>> On 28/11/11 12:07, Daniel Carrera wrote:
>>>> I need help understanding the "contains" statement. In particular,
>>>> why I
>>>> cannot have two contains statements in a program:
>
> I don't know why you cannot have another layer of internal procedures
> within an internal procedure, but the Fortran standard does not allow it.
>
> However, you can "nest" the "contains" statements in modules: The first
> "contains" tells you that now the module procedures come and within a
> module procedure, you can have internal procedures.
> (If you count type-bound procedures, you can have yet another layer with
> "contains", as Wolfgang showed.)
>
> For your problem: Generate a module, stuff in all of the procedures
> which were previously "contained" in the main program. Then you can also
> use an internal procedure. I think in nearly all cases, splitting off
> the declaration into a module removes the need to nest procedures within
> internal procedures.
>
> Tobias

On 11/28/11 1:47 AM, Tobias Burnus wrote:
> On 11/28/2011 08:37 AM, Wolfgang Kilian wrote:
>> On 11/28/2011 02:59 AM, Ian Harvey wrote:
>>> On 28/11/11 12:07, Daniel Carrera wrote:
>>>> I need help understanding the "contains" statement. In particular,
>>>> why I
>>>> cannot have two contains statements in a program:
>
> I don't know why you cannot have another layer of internal procedures
> within an internal procedure, but the Fortran standard does not allow it.

But, that is the reason, so you actually do know why. ;)

If I recall correctly, the thing that drove the initial decision to 
limit it to one deep was the recursive problem.  If you have nested 
recursive routines that invoke each other, perhaps indirectly, the 
belief was that it was just too difficult to sort out the stacks and get 
the right variables available in each instance.  I didn't say it is 
impossible.  I'm saying that the (perceived in the 80s) cost in run-time 
complexity (pronounced "slow-down") wasn't worth the small gain in 
programming ease.  Plus, if the standard allowed "only" two-deep 
nesting, someone would come along with a reasonable need for 
three-deep....

Dick Hendrickson
>
> However, you can "nest" the "contains" statements in modules: The first
> "contains" tells you that now the module procedures come and within a
> module procedure, you can have internal procedures.
> (If you count type-bound procedures, you can have yet another layer with
> "contains", as Wolfgang showed.)
>
> For your problem: Generate a module, stuff in all of the procedures
> which were previously "contained" in the main program. Then you can also
> use an internal procedure. I think in nearly all cases, splitting off
> the declaration into a module removes the need to nest procedures within
> internal procedures.
>
> Tobias

> So this is ok:
> MODULE a_module
> =A0 =A0IMPLICIT NONE
> CONTAINS
> =A0 =A0SUBROUTINE a_module_subprogram
> =A0 =A0CONTAINS
> =A0 =A0 =A0SUBROUTINE an_internal_subprogram
> =A0 =A0 =A0END SUBROUTINE an_internal_subprogram
> =A0 =A0END SUBROUTINE a_module_subprogram
> END MODULE a_module


Ohhhhhhh!!!! I have to confess that this is new for me! (-grin!-) What
a good news! And, if I may ask here, are all parameters passed to/from
"a_module_subprogram" (as I would expect) automatically known/
accessible to "an_internal_subprogram"? That would reduce the length
of some subroutine calls in my Modules!

Arjan

Arjan <arjan.van.dijk@rivm.nl> wrote:

> > So this is ok:
> > MODULE a_module
> >    IMPLICIT NONE
> > CONTAINS
> >    SUBROUTINE a_module_subprogram
> >    CONTAINS
> >      SUBROUTINE an_internal_subprogram
> >      END SUBROUTINE an_internal_subprogram
> >    END SUBROUTINE a_module_subprogram
> > END MODULE a_module
> 
> 
> Ohhhhhhh!!!! I have to confess that this is new for me! (-grin!-) What
> a good news! And, if I may ask here, are all parameters passed to/from
> "a_module_subprogram" (as I would expect) automatically known/
> accessible to "an_internal_subprogram"? That would reduce the length
> of some subroutine calls in my Modules!

Yes, but.... The question strikes me as slightly odd, suggesting to me
that perhaps you don't understand what is going on.

Everything in the host is accessible in an internal subprogram (unless
overridden by a local declaration of something with the same name).
There is nothing special at all in this regard about parameters (by
which I assume you really mean dummy arguments, but it would also be
true of actual Fortran parameters, aka named constants). That's what
makes me wonder about the question.

Note that an internal subprogram can be referenced *ONLY* from its host
subprogram or other internal subprograms of the same host. Your question
makes me suspect you might be thinking of calling the internal
subprogram from elsewhere and having it recall the last arguments that
the host was called with. Perhaps I'm completely off base in that guess,
but that's what asking about the arguments as something special makes me
think. That turns out to be a moot point as you can't call the internal
subprogram from outside its host at all.

An internal subprogram is not at all like a module subprogram in that
way. I know some people use the term "contained subprogram/procedure"
for anything after a CONTAINS statement, but I don't like the term
because it lumps together things that don't share a lot of comonality. A
module procedure is not much like an internal procedure other than that
both happen to follow CONTAINS statements, and host association applies
to both.

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

On 29/11/11 06:47, Richard Maine wrote:
> Note that an internal subprogram can be referenced *ONLY* from its host
> subprogram or other internal subprograms of the same host...

Stop living in the past.  It hasn't been this way for about ten thousand 
hours now...  ;)

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

(snip, someone wrote)
>> I don't know why you cannot have another layer of internal procedures
>> within an internal procedure, but the Fortran standard does not allow it.

> But, that is the reason, so you actually do know why. ;)

I thought I remembered this being changed in F2008, though I
haven't looked recently.

> If I recall correctly, the thing that drove the initial decision to 
> limit it to one deep was the recursive problem.  If you have nested 
> recursive routines that invoke each other, perhaps indirectly, the 
> belief was that it was just too difficult to sort out the stacks and get 
> the right variables available in each instance.  

I believe it isn't easy, but (for comparison purposes only, and
not for any other reason) note that PL/I has had this ability
since the 1960's.  (And it may run slow, too.)

It would seem to me that most of the problem with nested recursive
routines is already that with one level.  Call back and forth
a few times between them and some other routines, and you already
have to keep track of which instance things belong to.

> I didn't say it is impossible.  I'm saying that the (perceived 
> in the 80s) cost in run-time complexity (pronounced "slow-down") 
> wasn't worth the small gain in programming ease.  

I understood that as the reason for not allowing internal
subroutines as actual arguments to other procedures.
(Though I believe that has changed in F2008.)  It isn't
so obvious in this case.  

> Plus, if the standard allowed "only" two-deep 
> nesting, someone would come along with a reasonable need for 
> three-deep....

Yes that is what happens.  

But once the problem is solved, it usually works for arbitrary
depth, until you run out of memory to keep track of them.
(Or at least arbitrary enough.)

-- glen

Ian Harvey <ian_harvey@bigpond.com> wrote:
> On 29/11/11 06:47, Richard Maine wrote:
>> Note that an internal subprogram can be referenced *ONLY* from its host
>> subprogram or other internal subprograms of the same host...

> Stop living in the past.  It hasn't been this way for about ten thousand 
> hours now...  ;)

I had thought that nested internal subroutines were also now allowed,
but now that I look I don't see it.  Maybe next time.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Ian Harvey <ian_harvey@bigpond.com> wrote:
> > On 29/11/11 06:47, Richard Maine wrote:
> >> Note that an internal subprogram can be referenced *ONLY* from its host
> >> subprogram or other internal subprograms of the same host...
> 
> > Stop living in the past.  It hasn't been this way for about ten thousand
> > hours now...  ;)
> 
> I had thought that nested internal subroutines were also now allowed,
> but now that I look I don't see it.  Maybe next time.

I'm afraid I'm missing something here. I presume the 10,000 hours is
probably a reference to f2008. I don't recall exactly when f2008 got
formal publication, but 10,000 hours ago seems at least the right order
of magnitude.

But to my knowledge, nothing in f2008 allows referencing an internal
subprogram from anyplace other than the host or another internal
subprogram of the same host. I don't see what nested internal procedures
would have to do with that. Hmm... I suppose that with recursion, the
"other" might be inaccurate, as it could also be referenced from itself.
That might be it, thought that's not quite directly related to nesting
either. I guess I really have no clue what Glen is alluding to.

But Ian might be alluding to being able to pass an internal procedure as
an actual argument or have it be a pointer target. I think those are
allowed in f2008. They do allow invoking the internal procedure from
other scopes, but in a weak attempt to salvage my credibility, I'll
claim that those are not strictly speaking "references". If I recall
correctly (and no, I didn't take the time to check) a "reference" is
technically an appearance in the source code. If you have, for example,
an internal procedure as the target of a procedure pointer, you can then
reference the pointer in order to invoke the procedure, but I think the
"reference" is only to the pointer. (Yes, I'm being deliberately
pedantic just to avoid saying I was wrong. :-))

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

On 29/11/11 12:46, Richard Maine wrote:
> glen herrmannsfeldt<gah@ugcs.caltech.edu>  wrote:
>
>> Ian Harvey<ian_harvey@bigpond.com>  wrote:
>>> On 29/11/11 06:47, Richard Maine wrote:
>>>> Note that an internal subprogram can be referenced *ONLY* from its host
>>>> subprogram or other internal subprograms of the same host...
>>
>>> Stop living in the past.  It hasn't been this way for about ten thousand
>>> hours now...  ;)
>>
>> I had thought that nested internal subroutines were also now allowed,
>> but now that I look I don't see it.  Maybe next time.
>
> I'm afraid I'm missing something here. I presume the 10,000 hours is
> probably a reference to f2008. I don't recall exactly when f2008 got
> formal publication, but 10,000 hours ago seems at least the right order
> of magnitude.
>
> But to my knowledge, nothing in f2008 allows referencing an internal
> subprogram from anyplace other than the host or another internal
> subprogram of the same host. I don't see what nested internal procedures
> would have to do with that. Hmm... I suppose that with recursion, the
> "other" might be inaccurate, as it could also be referenced from itself.
> That might be it, thought that's not quite directly related to nesting
> either. I guess I really have no clue what Glen is alluding to.
>
> But Ian might be alluding to being able to pass an internal procedure as
> an actual argument or have it be a pointer target. I think those are
> allowed in f2008. They do allow invoking the internal procedure from
> other scopes, but in a weak attempt to salvage my credibility, I'll
> claim that those are not strictly speaking "references". If I recall
> correctly (and no, I didn't take the time to check) a "reference" is
> technically an appearance in the source code. If you have, for example,
> an internal procedure as the target of a procedure pointer, you can then
> reference the pointer in order to invoke the procedure, but I think the
> "reference" is only to the pointer. (Yes, I'm being deliberately
> pedantic just to avoid saying I was wrong. :-))

Yes - that was supposed to be about that internal procedure/actual 
argument/pointer target/etc bit of F2008.  I'll sheepishly back down now 
- but only because you originally had "subprogram reference", as opposed 
to procedure reference.  Your subsequent attempt to bend the meaning of 
"reference" in the context of procedures is just digging a hole for 
yourself when you didn't need to...

Richard Maine <nospam@see.signature> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>> Ian Harvey <ian_harvey@bigpond.com> wrote:
>> > On 29/11/11 06:47, Richard Maine wrote:
>> >> Note that an internal subprogram can be referenced *ONLY* from its host
>> >> subprogram or other internal subprograms of the same host...
 
>> > Stop living in the past.  It hasn't been this way for about ten thousand
>> > hours now...  ;)
 
>> I had thought that nested internal subroutines were also now allowed,
>> but now that I look I don't see it.  Maybe next time.

> I'm afraid I'm missing something here. I presume the 10,000 hours is
> probably a reference to f2008. I don't recall exactly when f2008 got
> formal publication, but 10,000 hours ago seems at least the right order
> of magnitude.

Close enough for me.

> But to my knowledge, nothing in f2008 allows referencing an internal
> subprogram from anyplace other than the host or another internal
> subprogram of the same host. I don't see what nested internal procedures
> would have to do with that. Hmm... I suppose that with recursion, the
> "other" might be inaccurate, as it could also be referenced from itself.
> That might be it, thought that's not quite directly related to nesting
> either. I guess I really have no clue what Glen is alluding to.

F2008 allows internal procedures as dummy arguments, such that
they can be called (if not referenced) from other procedures.

> But Ian might be alluding to being able to pass an internal procedure as
> an actual argument or have it be a pointer target. I think those are
> allowed in f2008. 

(snip)

I am not sure by now how this got into the discussion, but it
is a different question from nested internal procedures.

I had separately thought that nested internal procedures were
allowed in F2008, but it seems not.  

There is a book, "History of Programming Languages" as the
final proceedings of an ACM conference in June 1978.  Among
others, there is much discussion on Fortran and PL/I.
(ALGOL seems to have the longest chapter.)  

Among the PL/I chapter descriptions is the schedule for the
definition of NPL (before the name was changed).  The first
meeting was in October 1963 with a deadline of December 1963
for the language specification.  That deadline was then
extended to January and later to February 1964.

It has always seemed to me that PL/I was more consistent,
or what CS often calls orthogonal, than Fortran.  If you can
do something in one place, and it makes sense in another
place, then it should work the same way.  That isn't
always true, but most of the time it is.  Among others,
that allows for nested internal procedures.

While one may not start out needing nested internal procedures,
if one has a procedure with internal procedures, and the desire
to use that as an internal procedure, nesting is natural.

(It seems that in some of the earlier meetings, the new language
was being referred to as Fortran VI.)

  "FORTRAN VI is not intended to be compatible with any known
   FORTRAN IV.  It includes the functional capabilities of FORTRAN IV
   as well as those capabilities normally associated with
   "commercial" and "algorithmic" languages.  In order to embrace
   these capabilities in a usable and practical language, it has
   been found virtually impossible, and ceratainly undesirable,
   to retain FORTRAN IV as a compatible subset."

To get back to the subject, I might see why nested internal
procderes were not added by Fortran 90 or 95, but it would
seem that F2008 should have added them.  Are they on the
list for F2013?

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine <nospam@see.signature> wrote:

> > But Ian might be alluding to being able to pass an internal procedure as
> > an actual argument or have it be a pointer target. I think those are
> > allowed in f2008. 
> 
> I am not sure by now how this got into the discussion, but it
> is a different question from nested internal procedures.

Yes, exactly. Which is why I was surprised that you brought up nested
internal procedures in reply to it.

As to how it got there, that's simple enough. I speculated (said
speculation being a bit weak and still unverified) that Arjan's
question, which started the subthread, might imply that he thought you
could reference an internal subprogram from outside its host, and I
explained that you can't do that. Ian said that I was wrong, leaving it
to the reader to deduce why. (And Ian was correct, except for word-game
niggles that I played to pretend otherwise). Ian's allusion, as he later
verified, was to the use of internal procedures as actual arguments or
pointer targets. So far, I follow it.

Then you brought up nested internal procedures. I agree that's a
completely different question and I have no idea why you brought it up.
My only guess is that you were conflating this subthread with part of
the other subthread, which was about nested internal procedures. *THIS*
subthread started with Arjan's question about whether internal
procedures had acess to the dummy arguments of their host procedures; I
see no relationship between that and nesting.

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

Richard Maine <nospam@see.signature> wrote:

(snip)
>> I am not sure by now how this got into the discussion, but it
>> is a different question from nested internal procedures.

> Yes, exactly. Which is why I was surprised that you brought up nested
> internal procedures in reply to it.

(snip)

> Then you brought up nested internal procedures. I agree 
> that's a completely different question and I have no idea 
> why you brought it up.

> My only guess is that you were conflating this subthread 
> with part of the other subthread, which was about nested 
> internal procedures. 

I don't know about subthreads, the first post of the thread
is netsted internal procedures.  If it starts a new thread
with a new name, then I will follow it separately.
(Or at least try.  Sometimes they do get connected.)

In any case, I believe that both nested internal procedures
and actual arguments of internal procdures or pointers to
internal procedures should be part of the standard.  


-- glen

On 11/29/2011 08:22 AM, glen herrmannsfeldt wrote:
> Richard Maine<nospam@see.signature>  wrote:
>
> (snip)
>>> I am not sure by now how this got into the discussion, but it
>>> is a different question from nested internal procedures.
>
>> Yes, exactly. Which is why I was surprised that you brought up nested
>> internal procedures in reply to it.
>
> (snip)
>
>> Then you brought up nested internal procedures. I agree
>> that's a completely different question and I have no idea
>> why you brought it up.
>
>> My only guess is that you were conflating this subthread
>> with part of the other subthread, which was about nested
>> internal procedures.
>
> I don't know about subthreads, the first post of the thread
> is netsted internal procedures.  If it starts a new thread
> with a new name, then I will follow it separately.
> (Or at least try.  Sometimes they do get connected.)
>
> In any case, I believe that both nested internal procedures
> and actual arguments of internal procdures or pointers to
> internal procedures should be part of the standard.
>
>
> -- glen

A feature of internal procedures is that they have unlimited access to 
variables of their host.  Once they are used nonlocally, this can turn 
into a problem because you can get unwanted nonlocal side-effects.  In 
case of nesting, you may forget to declare a local variable, and modify 
a host variable several levels up.  If the internal procedure is used 
elsewhere --

I would propose (as others did before) to have some 'import' statement 
for internal procedures, and encourage 'import none'.

-- Wolfgang

-- 
E-mail: firstnameinitial.lastname@domain.de
Domain: yahoo

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine <nospam@see.signature> wrote:
> 
> (snip)
> >> I am not sure by now how this got into the discussion, but it
> >> is a different question from nested internal procedures.
> 
> > Yes, exactly. Which is why I was surprised that you brought up nested
> > internal procedures in reply to it.
> 
> (snip)
> 
> > Then you brought up nested internal procedures. I agree 
> > that's a completely different question and I have no idea 
> > why you brought it up.
> 
> > My only guess is that you were conflating this subthread 
> > with part of the other subthread, which was about nested 
> > internal procedures. 
> 
> I don't know about subthreads, the first post of the thread
> is netsted internal procedures.  If it starts a new thread
> with a new name, then I will follow it separately.
> (Or at least try.  Sometimes they do get connected.)

Yes, that would explain the confusion if your newsreader doesn't make
subthreads evident. Hmm. That might also explain some other sudden
changes of subject in the past; I noticed it happening, but that
possible explanation hadn't occurred to me.

I try to quote adequate context (while snipping the larger bulk to avoid
even more excess verbiage than my own writing provides), but without
references headers you must have a really hard time with the posters who
occasionally reply with no context at all unless it is in a small enough
thread that it is evident what it must refer to.

One of the things I particularly like about the newsreader I use
(MacSOUP, unfortunately for Macs only) is that it does an excellent job
of visually showing the relationships between posts based on the
References headers. Counting on subject names is not reliable; that's
what the references headers are for.

I know that very few readers do as good a job as MacSOUP, but I thought
most if them did at least a token job.

I'm pretty sure I at least briefly tried tin (the newsreader you appear
to be using) once, but it was long enough ago that I recall no details
at all - certainly not such things as how it handles references.

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

> Your question makes me suspect you might be thinking of calling the internal
> subprogram from elsewhere and having it recall the last arguments that
> the host was called with. Perhaps I'm completely off base in that guess,
> but that's what asking about the arguments as something special makes me
> think. That turns out to be a moot point as you can't call the internal
> subprogram from outside its host at all.


Yes, you were off base, but I appreciate your additional explanation
anyhow! Sorry for my sloppy terminology ("parameter", etc.)!

Quite often, I have auxiliary subroutines that are ultimately
specific, in this sense that they are called by only 1 other
subroutine. I was unaware of the just given possibilities, and
therefore had these subroutines inside the same Module as the mother
routine, but otherwise fully independent. So to enable these
ultimately specific subroutines to do their task in the correct
context, I had to pass the whole context to them, from mother to
daughter. Now I know that this is not necessary, and that I can place
the whole ultimately specific subroutines inside their "owning" mother
routine. This is going to allow me to reduce the passing of context.

I won't dare call such a routine from outside its scope!

Arjan

Arjan <arjan.van.dijk@rivm.nl> wrote:
(previous snip, someone wrote)
>> Your question makes me suspect you might be thinking of calling the internal
>> subprogram from elsewhere and having it recall the last arguments that
>> the host was called with. Perhaps I'm completely off base in that guess,
>> but that's what asking about the arguments as something special makes me
>> think. That turns out to be a moot point as you can't call the internal
>> subprogram from outside its host at all.

> Yes, you were off base, but I appreciate your additional explanation
> anyhow! Sorry for my sloppy terminology ("parameter", etc.)!

> Quite often, I have auxiliary subroutines that are ultimately
> specific, in this sense that they are called by only 1 other
> subroutine. I was unaware of the just given possibilities, and
> therefore had these subroutines inside the same Module as the mother
> routine, but otherwise fully independent. 

Yes, this seems to be a good use for internal procedures.
Among others, that way someone reading the outer procedure doesn't
have to search around for the subprocedure.  Especially if it is
small and not otherwise useful, even if it doesn't use any context
from the parent.

> So to enable these ultimately specific subroutines to do their 
> task in the correct context, I had to pass the whole context to 
> them, from mother to daughter. 

> Now I know that this is not necessary, and that I can place
> the whole ultimately specific subroutines inside their "owning" mother
> routine. This is going to allow me to reduce the passing of context.

> I won't dare call such a routine from outside its scope!

That is the feature not added until Fortran 2008.  One use that
might come up is calling another routine, passing the internal
procedure as an actual argument (or as a procedure pointer), where
that routine then calls the internal procedure, with its context.

One example is an integration routine that evaluates a given
function at different points, but where host context is also
needed.  The traditional way (from Fortran II through Fortran 77)
was to put the context in COMMON.  With MODULEs, one can pass
context through that way, but the effect is pretty much the same
as with COMMON.  (Among others, it fails with recursion.)

If I understand it right, an internal procedure passed as an 
actual argument carries the specific (in the case of recursion) 
context along, even when called indirectly.

-- glen

On 11/29/2011 08:07 PM, glen herrmannsfeldt wrote:
[...]
> One example is an integration routine that evaluates a given
> function at different points, but where host context is also
> needed.  The traditional way (from Fortran II through Fortran 77)
> was to put the context in COMMON.  With MODULEs, one can pass
> context through that way, but the effect is pretty much the same
> as with COMMON.  (Among others, it fails with recursion.)
>
> If I understand it right, an internal procedure passed as an
> actual argument carries the specific (in the case of recursion)
> context along, even when called indirectly.
>
> -- glen
>

There is also the OO alternative (Fortran 2003): wrap the procedure plus 
context as a derived type which has the procedure as a TBP (or as a 
procedure pointer, whichever fits better).  With the passed-object 
mechanism, the procedure can access its context.  [If the derived type 
is the extension of an abstract type which only has the TBP (deferred), 
the integration routine need not know anything about specific procedures 
or their context.]

I would avoid calling internal procedures from outside their host, maybe 
because I don't like side effects.

-- Wolfgang

-- 
E-mail: firstnameinitial.lastname@domain.de
Domain: yahoo