I asked something similar here recently, but I'm not sure I conveyed 
what I wanted to, so here is a fresh start.  Consider a collection of 
routines intended to be used as a black box:

MODULE STUFF

PRIVATE

!variables which are used internally by the various routines

!list of routines the user can call
PUBLIC :: 

CONTAINS

!various routines, some of which can be called by a user of this library 
!(see PUBLIC above) and others which are used only internally

The user needs to know the names of the routines and the data types of 
the arguments.

So far, so good.

Normally, the user would declare variables in his program which are used 
to call the routines.  For example,

SUBROUTINE BLA(X,Y,Z)

would mean that variables, say A, B, C, need to be declared which are 
then used to call BLA, perhaps in the style

CALL BLA(X=A,Y=B,Z=C)

Normally, the black box will be compiled and put in an object library 
then used by other programs which are written and compiled later.  The 
USE statement will allow compile-time checking.

All of this will work.  However, as far as I know the following is 
functionally equivalent:

MODULE STUFF

PRIVATE

!variables which are used internally by the various routines

!list of variables which the user can use in the program which calls the 
!routines below
PUBLIC ::

!list of routines the user can call
PUBLIC :: 

CONTAINS

!various routines, some of which can be called by a user of this library 
!(see PUBLIC above) and others which are used only internally

In other words, instead of declaring them in the calling program, A, B 
and C are declared in the black box and accessed via USE by the calling 
program.  AS LONG AS NOTHING IN THE MODULE DOES ANYTHING WITH THESE 
VARIABLES APART FROM DECLARING THEM, is there any reason not to do this?
The advantage is that the user doesn't have to put the declarations in 
the (possibly quite short) calling programs.  Of course, the user has to 
know what the variables are called, so he has to look at the code (or 
the documentation) for the black box, but he has to do that anyway to 
know what data types the arguments have.

On 12 feb, 13:21, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> I asked something similar here recently, but I'm not sure I conveyed
> what I wanted to, so here is a fresh start. =A0Consider a collection of
> routines intended to be used as a black box:
>
> MODULE STUFF
>
> PRIVATE
>
> !variables which are used internally by the various routines
>
> !list of routines the user can call
> PUBLIC ::
>
> CONTAINS
>
> !various routines, some of which can be called by a user of this library
> !(see PUBLIC above) and others which are used only internally
>
> The user needs to know the names of the routines and the data types of
> the arguments.
>
> So far, so good.
>
> Normally, the user would declare variables in his program which are used
> to call the routines. =A0For example,
>
> SUBROUTINE BLA(X,Y,Z)
>
> would mean that variables, say A, B, C, need to be declared which are
> then used to call BLA, perhaps in the style
>
> CALL BLA(X=3DA,Y=3DB,Z=3DC)
>
> Normally, the black box will be compiled and put in an object library
> then used by other programs which are written and compiled later. =A0The
> USE statement will allow compile-time checking.
>
> All of this will work. =A0However, as far as I know the following is
> functionally equivalent:
>
> MODULE STUFF
>
> PRIVATE
>
> !variables which are used internally by the various routines
>
> !list of variables which the user can use in the program which calls the
> !routines below
> PUBLIC ::
>
> !list of routines the user can call
> PUBLIC ::
>
> CONTAINS
>
> !various routines, some of which can be called by a user of this library
> !(see PUBLIC above) and others which are used only internally
>
> In other words, instead of declaring them in the calling program, A, B
> and C are declared in the black box and accessed via USE by the calling
> program. =A0AS LONG AS NOTHING IN THE MODULE DOES ANYTHING WITH THESE
> VARIABLES APART FROM DECLARING THEM, is there any reason not to do this?
> The advantage is that the user doesn't have to put the declarations in
> the (possibly quite short) calling programs. =A0Of course, the user has t=
o
> know what the variables are called, so he has to look at the code (or
> the documentation) for the black box, but he has to do that anyway to
> know what data types the arguments have.

This will definitely work in terms of the standard. Whether it is a
convenient way to work, is another matter. For instance:
- What would you if the black box is to be used in multiprocessing
  (or multithreading) environment? The variables you have defined
  for the user to use would be shared among the threads, necessitating
  synchronisation and locking.
- What if the user needs to use the black box in several places,
  wouldn't the use of the same variables all over the program lead
  to confusion?

I think the gain (no black box-specific declarations in the user's
code)
is not large enough to undo the disadavantages.

Regards,

Arjen

In article
<7e5c9c9a-6304-4010-83f3-019e18a5b5e4@bs8g2000vbb.googlegroups.com>,
Arjen Markus <arjen.markus895@gmail.com> writes: 

> This will definitely work in terms of the standard. Whether it is a
> convenient way to work, is another matter. For instance:
> - What would you if the black box is to be used in multiprocessing
>   (or multithreading) environment? The variables you have defined
>   for the user to use would be shared among the threads, necessitating
>   synchronisation and locking.

I don't have any experience with multithreaded Fortran.  Would this not 
be an issue if the variables are defined in the users own code?

> - What if the user needs to use the black box in several places,
>   wouldn't the use of the same variables all over the program lead
>   to confusion?

You mean something like 

   CALL BLA(A,B,C) 

where A, B and C are the variables declared outside the routine (i.e. in 
the user's code or at the top of the module) then later

   CALL BLA(D,E,F)

where D is a different input variable than A, say, and E and F are 
different output variables than B and C?

If so, good point!

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> I asked something similar here recently, but I'm not sure I conveyed 
> what I wanted to, so here is a fresh start.
[much elided]
> In other words, instead of declaring them in the calling program, A, B
> and C are declared in the black box and accessed via USE by the calling
> program.  AS LONG AS NOTHING IN THE MODULE DOES ANYTHING WITH THESE 
> VARIABLES APART FROM DECLARING THEM, is there any reason not to do this?
> The advantage is that the user doesn't have to put the declarations in
> the (possibly quite short) calling programs.  Of course, the user has to
> know what the variables are called, so he has to look at the code (or
> the documentation) for the black box, but he has to do that anyway to
> know what data types the arguments have.

I'm in a bit of a hurry, but then the time seems adequate for what I
have to say anyway. Looks exactly like what I read before, not just
simillar. I'll not try to repeat all the reasons, partly because I don't
have time right now, and partly because it would just be repetitive
anyway.

I personally think it is a really bad idea, Anything even similar would
also be a bad idea. I don't even think the objectives are good. That
kind of objective is not going to get you to good ends. Well intentioned
though they may be, ithey are a path to buggy code.

Sorry if this seems a bit abrupt, but I do believe this was adequately
covered before and I don't see how "a fresh start" is going to change
anything. I'm going to try very hard not to post further on it.

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

In article <1kfce0a.ocx7rc7xubzoN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes: 

> I'm in a bit of a hurry, but then the time seems adequate for what I
> have to say anyway. Looks exactly like what I read before, not just
> simillar. I'll not try to repeat all the reasons, partly because I don't
> have time right now, and partly because it would just be repetitive
> anyway.
> 
> I personally think it is a really bad idea, Anything even similar would
> also be a bad idea. I don't even think the objectives are good. That
> kind of objective is not going to get you to good ends. Well intentioned
> though they may be, ithey are a path to buggy code.
> 
> Sorry if this seems a bit abrupt, but I do believe this was adequately
> covered before and I don't see how "a fresh start" is going to change
> anything. I'm going to try very hard not to post further on it.

I'm now convinced that it's a bad idea.  :-|

On 2012-02-12 12:18:11 -0400, Phillip Helbig---undress to reply said:

> In article <1kfce0a.ocx7rc7xubzoN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes:
> 
>> I'm in a bit of a hurry, but then the time seems adequate for what I
>> have to say anyway. Looks exactly like what I read before, not just
>> simillar. I'll not try to repeat all the reasons, partly because I don't
>> have time right now, and partly because it would just be repetitive
>> anyway.
>> 
>> I personally think it is a really bad idea, Anything even similar would
>> also be a bad idea. I don't even think the objectives are good. That
>> kind of objective is not going to get you to good ends. Well intentioned
>> though they may be, ithey are a path to buggy code.
>> 
>> Sorry if this seems a bit abrupt, but I do believe this was adequately
>> covered before and I don't see how "a fresh start" is going to change
>> anything. I'm going to try very hard not to post further on it.
> 
> I'm now convinced that it's a bad idea.  :-|

I had (still have) a code which had one user entry point which internally
used several utilities and had all its important data in a data module.
A problem was solved by calling the entry point with an initial call flag
and then calling the entry point repeatedly with continuation flags. There
was even an ending flag. It worked smoothly for my dedicated application.
As a user I never needed to know what all was in that data module (even
though I was also the implementor).

Then one day I needed to solve two versions of my problem at once. Could
not do it as the data module could not be saved and restored between the
problems. Not unexpected and an obvious consequnce of plausible decisons
taken for convenience much before. But an real nuisance in the short run
at the time. (I duplicated the code and appended "2" to a number of
identifiers in the second copy. Yuck!)

Some time later I needed to multi-thread so I converted the data module into
a structure and required each use to supply a base pointer. Worked pretty
slickly as I did not have any saved information anywhere except in the 
components
of the structure (the old data module). It was a low fuss to switch to using
OpenMP.

So the lesson was that a set of hidden states in a data module was bad news
once I needed more that one dedicated problem. Blindingly obvious even before
the first coffee of the day. If the data module (it used to be a common block)
is cleanly set up it is easy to make it a structure and things will be thread
safe on a reasonable compiler. Then one can solve two or N versions of the
problem at once. Solving the N-at-once problem was easier then the 2-at-once
problem as it quite common.

All of this is just an explicit story to make the point which has been made
more abstractly already. A package with hidden states is convenient until
it becomes a stumbling block. The transition is when you need to do two
or more versions of the same problem. Both two and more have a habit of
showing up for useful packages.

Gordon Sande <Gordon.Sande@gmail.com> wrote:

> All of this is just an explicit story to make the point which has been made
> more abstractly already. A package with hidden states is convenient until
> it becomes a stumbling block. The transition is when you need to do two
> or more versions of the same problem. Both two and more have a habit of
> showing up for useful packages.

My willpower is obviously weak today in that I'm replying again. :-(

Note that the notion on the table was, from my viewpoint, actually worse
than having a package with hidden state. note Philip's comment that

>> NOTHING IN THE MODULE DOES ANYTHING WITH THESE 
>> VARIABLES APART FROM DECLARING THEM

To me, that's dragging in all of the problems of hidden states, without
actually having the advantages. If they were actually hidden states,
then everything relating to them would be done in the module instead of
nothing. As I mentioned in the prior threads, it seems to me like trying
to somehow split the difference between putting the data in the module
versus passing it as arguments. This case puts the data in the module,
like you would for hidden states, but then passes it as arguments anyway
instead of directly using it from the module.

I think that manages to combine some of the worst parts of each option.
You still have to pass the data in just as though it were not data in
the module. The *ONLY* thing it "saves" is writing the declarations in
the calling code.

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

On 12 feb, 16:57, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article
> <7e5c9c9a-6304-4010-83f3-019e18a5b...@bs8g2000vbb.googlegroups.com>,
>
> Arjen Markus <arjen.markus...@gmail.com> writes:
> > This will definitely work in terms of the standard. Whether it is a
> > convenient way to work, is another matter. For instance:
> > - What would you if the black box is to be used in multiprocessing
> > =A0 (or multithreading) environment? The variables you have defined
> > =A0 for the user to use would be shared among the threads, necessitatin=
g
> > =A0 synchronisation and locking.
>
> I don't have any experience with multithreaded Fortran. =A0Would this not
> be an issue if the variables are defined in the users own code?
>

Sure, but then it is the user's responsibility to get that right.
For instance, using OpenMP you can define these variables as being
private to the thread, whereas if they are defined in the module,
he/she has no control.

> > - What if the user needs to use the black box in several places,
> > =A0 wouldn't the use of the same variables all over the program lead
> > =A0 to confusion?
>
> You mean something like
>
> =A0 =A0CALL BLA(A,B,C)
>
> where A, B and C are the variables declared outside the routine (i.e. in
> the user's code or at the top of the module) then later
>
> =A0 =A0CALL BLA(D,E,F)
>
> where D is a different input variable than A, say, and E and F are
> different output variables than B and C?
>
> If so, good point!

That is what I mean ;).

Regards,

Arjen