Suppose one have module:

---------- m.f90 ---------
module m
   public
      integer :: z;
end module m
--------------

and program that uses the above module:

---------- test_m.f90 ----------
program test_m
use m
implicit none
z = 5;
end
--------------------

The above works OK. But I'd rather be explicit in saying in which
module the variable z is in. So I wanted to write

-------------------
program test_m
implicit none

m%z = 5;  (or m.z or something like that)

end
-------------------

But that does not work. This also do not work:

---------------------
program test_m
USE m
implicit none

m%z = 5;

end
---------------------

I know, wrong syntax. It thinks 'm' is variable.

I want have the association to the module name be there,
where I can see it, and not global.

Because if one has 10 modules being USE'D, then one can more easily
see in the code which variable belongs to which module if the
module name can be part of the variable name.

Looked at many examples, but they all just do the global USE
and then in the code, just use whatever that module exports.

Any idea what is the right syntax to do what I want?

For example, in Ada, I can write   m.z=5; where m is a
package name, same as Fortran module.

thanks,
--Nasser

> Any idea what is the right syntax to do what I want?

See any decent Fortran reference about the use of
ONLY with a module.

--
steve

On 3/25/2011 7:59 PM, steve wrote:
>
>> Any idea what is the right syntax to do what I want?
>
> See any decent Fortran reference about the use of
> ONLY with a module.
>

I know about ONLY with USE. I've seen it, but that is not
what I am asking.

USE with ONLY, one lists the variables at the top which
are being used from the module.

I want to be able to have the module name as part of
the variable, in the code section. Otherwise, each
time one sees a variable, they have to go
to the top and see from which module this variable
came from.  Not efficient.

--Nasser

On 3/25/2011 10:10 PM, Nasser M. Abbasi wrote:
> On 3/25/2011 7:59 PM, steve wrote:
>>
>>> Any idea what is the right syntax to do what I want?
>>
>> See any decent Fortran reference about the use of
>> ONLY with a module.
>>
>
> I know about ONLY with USE. I've seen it, but that is not
> what I am asking.
>
> USE with ONLY, one lists the variables at the top which
> are being used from the module.
>
> I want to be able to have the module name as part of
> the variable, in the code section. Otherwise, each
> time one sees a variable, they have to go
> to the top and see from which module this variable
> came from. Not efficient.
>
> --Nasser
Name the variables to be exported from a module with inclusion of the 
module name or a synonym or shortened version.

On Mar 25, 8:10=A0pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 3/25/2011 7:59 PM, steve wrote:
>
>
>
> >> Any idea what is the right syntax to do what I want?
>
> > See any decent Fortran reference about the use of
> > ONLY with a module.
>
> I know about ONLY with USE. I've seen it, but that is not
> what I am asking.
>
> USE with ONLY, one lists the variables at the top which
> are being used from the module.
>
> I want to be able to have the module name as part of
> the variable, in the code section. Otherwise, each
> time one sees a variable, they have to go
> to the top and see from which module this variable
> came from. =A0Not efficient.
>
> --Nasser

On Mar 25, 8:10=A0pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 3/25/2011 7:59 PM, steve wrote:
>
>
>
> >> Any idea what is the right syntax to do what I want?
>
> > See any decent Fortran reference about the use of
> > ONLY with a module.
>
> I know about ONLY with USE. I've seen it, but that is not
> what I am asking.
>
> USE with ONLY, one lists the variables at the top which
> are being used from the module.
>
> I want to be able to have the module name as part of
> the variable, in the code section. Otherwise, each
> time one sees a variable, they have to go
> to the top and see from which module this variable
> came from. =A0Not efficient.
>

(Sorry about the blank reply hit the wrong button).

laptop:kargl[207] cat a.f90
module duh
  integer bar
end module duh

program foo
  use duh, only : duh_bar =3D> bar
  duh_bar =3D 1
  print *, duh_bar
end program foo
laptop:kargl[208] gfortran -o z a.f90
laptop:kargl[209] ./z
           1

On 3/25/2011 8:19 PM, Gary L. Scott wrote:

>>
>> I know about ONLY with USE. I've seen it, but that is not
>> what I am asking.
>>
>> USE with ONLY, one lists the variables at the top which
>> are being used from the module.
>>
>> I want to be able to have the module name as part of
>> the variable, in the code section. Otherwise, each
>> time one sees a variable, they have to go
>> to the top and see from which module this variable
>> came from. Not efficient.
>>
>> --Nasser

> Name the variables to be exported from a module with inclusion of the
> module name or a synonym or shortened version.

Thanks, but this sounds like a hack to me :)

There ought to be a way, in the code, to say

......
module_name<>variable_name = 5;
.....


Where <> is the thing I was looking for.  Can't use %,
and can't use '.'

It looks then that there is no such syntax in Fortran.

Ok. Issue closed for me. I just wanted to know if I
overlooked some syntax to do this while searching.

Thanks for the replies.

--Nasser

On Mar 25, 8:25=A0pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 3/25/2011 8:19 PM, Gary L. Scott wrote:
>
>
>
>
>
> >> I know about ONLY with USE. I've seen it, but that is not
> >> what I am asking.
>
> >> USE with ONLY, one lists the variables at the top which
> >> are being used from the module.
>
> >> I want to be able to have the module name as part of
> >> the variable, in the code section. Otherwise, each
> >> time one sees a variable, they have to go
> >> to the top and see from which module this variable
> >> came from. Not efficient.
>
> >> --Nasser
> > Name the variables to be exported from a module with inclusion of the
> > module name or a synonym or shortened version.
>
> Thanks, but this sounds like a hack to me :)
>
> There ought to be a way, in the code, to say
>
> .....
> module_name<>variable_name =3D 5;
> ....
>
> Where <> is the thing I was looking for. =A0Can't use %,
> and can't use '.'
>
> It looks then that there is no such syntax in Fortran.
>
> Ok. Issue closed for me. I just wanted to know if I
> overlooked some syntax to do this while searching.
>

Yes, you overlooked some syntax.  It is the rename facility
of the ONLY feature.

--
steve

steve <kargls@comcast.net> wrote:

> On Mar 25, 8:25 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> > On 3/25/2011 8:19 PM, Gary L. Scott wrote:
....
> > >> I want to be able to have the module name as part of
> > >> the variable, in the code section. Otherwise, each
> > >> time one sees a variable, they have to go
> > >> to the top and see from which module this variable
> > >> came from. Not efficient.
....
> > > Name the variables to be exported from a module with inclusion of the
> > > module name or a synonym or shortened version.
> >
> > Thanks, but this sounds like a hack to me :)
....
> > Ok. Issue closed for me. I just wanted to know if I
> > overlooked some syntax to do this while searching.
> >
> Yes, you overlooked some syntax.  It is the rename facility
> of the ONLY feature.

But if you are consistently going to do this in every place where you
USE the module, I'd think it would make a lot more sense to just name
the variable that way in the first place instead of naming it something
different and then renaming it to the form you actually want to use.

On the other hand, I don't see what is so hackish about naming the
variable the same way you intend to use it, so my perception of what
makes sense versus what is a hack is obviously different from the OP's.

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

"Nasser M. Abbasi" <nma@12000.org> wrote in message 
news:imjint$7h1$1@speranza.aioe.org...

> For example, in Ada, I can write   m.z=5; where m is a
> package name, same as Fortran module.

In Fortran, you could create a user-defined type and declare an
instance of it at module scope.  Are you sure that any language gets
namespace management prefect?  For example, in C++ you can delare
operators like operator=() but then to inform the reader just
which namespace b = a comes from you need something like
m::b.operator=(a), which I just can't force my optical preprocessors
to consider to be beautiful -- I'm not sure if that's correct.

That said, the standard is at best ambiguous if not downright buggy
on some aspects of namespace management, so you have to rely on
compiler bugs to make it work correctly sometimes.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

In article <1jype1e.yvdaqgnti00kN%nospam@see.signature>,
 nospam@see.signature (Richard Maine) wrote:

> steve <kargls@comcast.net> wrote:
> 
> > On Mar 25, 8:25 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> > > On 3/25/2011 8:19 PM, Gary L. Scott wrote:
> ...
> > > >> I want to be able to have the module name as part of
> > > >> the variable, in the code section. Otherwise, each
> > > >> time one sees a variable, they have to go
> > > >> to the top and see from which module this variable
> > > >> came from. Not efficient.
> ...
> > > > Name the variables to be exported from a module with inclusion of the
> > > > module name or a synonym or shortened version.
> > >
> > > Thanks, but this sounds like a hack to me :)
> ...
> > > Ok. Issue closed for me. I just wanted to know if I
> > > overlooked some syntax to do this while searching.
> > >
> > Yes, you overlooked some syntax.  It is the rename facility
> > of the ONLY feature.
> 
> But if you are consistently going to do this in every place where you
> USE the module, I'd think it would make a lot more sense to just name
> the variable that way in the first place instead of naming it something
> different and then renaming it to the form you actually want to use.
> 
> On the other hand, I don't see what is so hackish about naming the
> variable the same way you intend to use it, so my perception of what
> makes sense versus what is a hack is obviously different from the OP's.

This is my opinion too.  Just name the variable m_z or something 
similar.  This is a simple problem with a simple solution.  No need 
to make it complicated.

$.02 -Ron Shepard

On 03/26/2011 04:57 AM, Richard Maine wrote:
> But if you are consistently going to do this in every place where you
> USE the module, I'd think it would make a lot more sense to just name
> the variable that way in the first place instead of naming it something
> different and then renaming it to the form you actually want to use.
>
> On the other hand, I don't see what is so hackish about naming the
> variable the same way you intend to use it, so my perception of what
> makes sense versus what is a hack is obviously different from the OP's.

Perhaps he does not want to do this /consistently/. An example from 
Metcalf's book: You might have a "math" module and a "stats" module both 
of which have a function called "mean". In general, you just import 
"mean" as it is, but when you use both modules, you rename those 
functions to "math_mean" ans "stats_mean".

Daniel.

On 3/25/2011 8:57 PM, Richard Maine wrote:

>
> But if you are consistently going to do this in every place where you
> USE the module, I'd think it would make a lot more sense to just name
> the variable that way in the first place instead of naming it something
> different and then renaming it to the form you actually want to use.
>

I think this is a terrible design solution to a simple problem.

So, If I look at source code and see this

foo_z = 5;

Then the above could now mean, z is a variable in module foo, becuase
someone at the top of the source file has renamed it when they did

  USE foo;

or it could be just a variable foo_z, local to the program, or
it could be a variable in module boo, happened to be named foo_z
as in

USE boo; % this contains variable foo_z

So, to name it, one would write

boo_foo_z = 5

etc....

It seems to me the correct solution to this is to do like
the other languages have done:

In c++  one can write  foo::z, and in Ada foo.z, same in Java
foo.z, etc... where foo in the package or module name.

This problem has been solved long time ago. Just pre-append
the package/module name to the variable, using special character.

--Nasser

On Mar 25, 8:57=A0pm, nos...@see.signature (Richard Maine) wrote:
> steve <kar...@comcast.net> wrote:
> > On Mar 25, 8:25 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> > > On 3/25/2011 8:19 PM, Gary L. Scott wrote:
> ...
> > > >> I want to be able to have the module name as part of
> > > >> the variable, in the code section. Otherwise, each
> > > >> time one sees a variable, they have to go
> > > >> to the top and see from which module this variable
> > > >> came from. Not efficient.
> ...
> > > > Name the variables to be exported from a module with inclusion of t=
he
> > > > module name or a synonym or shortened version.
>
> > > Thanks, but this sounds like a hack to me :)
> ...
> > > Ok. Issue closed for me. I just wanted to know if I
> > > overlooked some syntax to do this while searching.
>
> > Yes, you overlooked some syntax. =A0It is the rename facility
> > of the ONLY feature.
>
> But if you are consistently going to do this in every place where you
> USE the module, I'd think it would make a lot more sense to just name
> the variable that way in the first place instead of naming it something
> different and then renaming it to the form you actually want to use.
>
> On the other hand, I don't see what is so hackish about naming the
> variable the same way you intend to use it, so my perception of what
> makes sense versus what is a hack is obviously different from the OP's.

I most certainly agree with you.  Seems Nasser is searching for a
complicated solution to a non-problem.  I thought I would give him
a solution.  With renaming, Nasser can do

   use foo, only : foo_bar =3D> bar
or
   use foo, only : bar_from_module_foo =3D> bar
or
   use foo, only : module_foo_contains_bar =3D> bar

--
steve

On Mar 26, 4:51=A0am, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 3/25/2011 8:57 PM, Richard Maine wrote:
>
>
>
> > But if you are consistently going to do this in every place where you
> > USE the module, I'd think it would make a lot more sense to just name
> > the variable that way in the first place instead of naming it something
> > different and then renaming it to the form you actually want to use.
>
> I think this is a terrible design solution to a simple problem.
>
> So, If I look at source code and see this
>
> foo_z =3D 5;
>
> Then the above could now mean, z is a variable in module foo, becuase
> someone at the top of the source file has renamed it when they did
>
> =A0 USE foo;
>
> or it could be just a variable foo_z, local to the program, or
> it could be a variable in module boo, happened to be named foo_z
> as in

Sigh.  Fortran is not Matlab, C++, Java, pet language of the month.

You can solve your non-problem by renaming the variable.

  use foo, only : z_is_from_module_foo =3D> z

--
steve

On Mar 26, 1:02=A0pm, steve <kar...@comcast.net> wrote:
> Sigh. =A0Fortran is not Matlab, C++, Java, pet language of the month.
>
> You can solve your non-problem by renaming the variable.
>
> =A0 use foo, only : z_is_from_module_foo =3D> z


It might be an issue of coding style. It might be that C++ and Java
encourage you to write your code differently, in such a way that
writing "foo::z" is a good idea. If you are coming from those
languages and learn Fortran 95/2003 you can't understand how Fortran
could possibly work without feature xyz.

From my point of view, my nearest experience is with Perl and Python.
Those languages allow both options. You can use $foo::z in Perl, or
you can import the variable and just call it $z. Python is similar.
Somehow, I have never felt the need to use $foo::z. The facility is
there, but I never use it. I feel that my code is clearer and cleaner
without the foo:: prefix. So when I learned Fortran last year, it
never occurred to me that there was anything missing because you can't
do foo::z.

I'm reminded of how Java programmers usually try to make JavaScript
look like Java, so they never learn the interesting features that
JavaScript has (functional programming, closures, prototypal
inheritance, etc.).

Daniel.

On 3/25/2011 10:25 PM, Nasser M. Abbasi wrote:
> On 3/25/2011 8:19 PM, Gary L. Scott wrote:
>
>>>
>>> I know about ONLY with USE. I've seen it, but that is not
>>> what I am asking.
>>>
>>> USE with ONLY, one lists the variables at the top which
>>> are being used from the module.
>>>
>>> I want to be able to have the module name as part of
>>> the variable, in the code section. Otherwise, each
>>> time one sees a variable, they have to go
>>> to the top and see from which module this variable
>>> came from. Not efficient.
>>>
>>> --Nasser
>
>> Name the variables to be exported from a module with inclusion of the
>> module name or a synonym or shortened version.
>
> Thanks, but this sounds like a hack to me :)
>
> There ought to be a way, in the code, to say
>
> .....
> module_name<>variable_name = 5;
> ....
>
>
> Where <> is the thing I was looking for. Can't use %,
> and can't use '.'
>
> It looks then that there is no such syntax in Fortran.
>
> Ok. Issue closed for me. I just wanted to know if I
> overlooked some syntax to do this while searching.
>
> Thanks for the replies.
>
> --Nasser
It is in general a bad idea to rename variables.  It is better to have a 
global naming convention that differentiates between local and imported 
variable.  In other words, if a module is specifically designed for 
variables to be exported, it should be clear already in the importing 
code that it is an imported variable.  That is a better design 
philosophy than local renaming.

In article <imkk08$c6p$1@speranza.aioe.org>,
 "Nasser M. Abbasi" <nma@12000.org> wrote:

> It seems to me the correct solution to this is to do like
> the other languages have done:
> 
> In c++  one can write  foo::z, and in Ada foo.z, same in Java
> foo.z, etc... where foo in the package or module name.
> 
> This problem has been solved long time ago. Just pre-append
> the package/module name to the variable, using special character.

I agree that this was a choice made in the language a long time ago.  
This choice was made in the mid 1980's and standardized in f90.  I 
have not used ada, so maybe that predates the fortran design, but 
other languages like perl and java, which do address this problem in 
different ways, came after fortran, not before.  In a previous post 
I mentioned Mathematica, in which the scope of variables also causes 
numerous problems in large programs; that also came before fortran.

I agree that there are advantages and disadvantages of the various 
approaches.  I happen to like the way fortran did it because it 
scales to large programs better than the other choices without 
unnecessary complications.  The largest perl program in existence is 
quite small by fortran standards, so the tradeoffs between namespace 
pollution and simplicity are different.

In fortran, if you want to keep track of where variables come from, 
then make it a point to use the ONLY clause in your USE statements.  
I think in many cases that is a good idea, but in other situations 
it is unnecessarily verbose.

If you need to rename variables or subprograms in order to avoid 
conflicts, then you can do that.  If not, then you can keep things 
simple.

Also, if you use fortran modules written by other people, you do not 
need to know the details of how those modules are implemented to use 
the information in them, you only need the API to that module.  If 
you import someone else's module A, which has some variable Z, then 
you can just reference Z in the normal way (or you can rename it 
locally, as you choose).  You do not need to know that in the 
implementation of that module, the variable was actually declared in 
module D, which was used by module C, which was then used by module 
B, which was then used by module A.  In other languages, you would 
need to know all of that in your code and reference the variable as 
A.B.C.D.Z (or something analogous).  Then if module A were 
subsequently rewritten and rearranged and Z was moved around, all of 
your user code that referenced A.B.C.D.Z would need to be changed to 
A.NEWB.NEWC.NEWD.NEWE.NEWF.Z or whatever.  And the same problem 
would apply to every other variable in that module that you accessed 
in your code.  For large programs written and maintained by a large 
number of programmers, that is a nice feature of the fortran 
implementation.  It allows "what is written is Vegas to stay in 
Vegas" without coming back and causing problems later.

On the other hand, if you want variables like that to have their 
ancestry exposed, then in module D you can define the variable to be 
D_Z.  Then in module C you can rename it to C_D_Z, and in module B 
you can rename it to B_C_D_Z, and finally in A you can rename it to 
A_B_C_D_Z.  That way you get what you seem to think is a good idea, 
but it is not imposed on you, you have the choice to implement it 
this way or not.

Now after saying all that, there are some odd things that can happen 
with nested modules.  For example, you sometimes think that you are 
renaming a variable in one module when actually you are renaming a 
variable in another module.  This is because the fortran compiler 
knows where all those module variables are really defined, and when 
you rename it in a USE statement, it covers that same variable in 
all modules which are USEd.  So I think that compilers should have 
an option to print out that information somehow to make it easier to 
track down these situations.

Here is a little example that demonstrates this:

module B
   integer :: Z=10
end module B

module A
   use B
end module A

program scope
   use A, W=>Z
   use B         ! you think you are accessing Z here.
   implicit none
   write(*,*) 'W=', W
   write(*,*) 'Z=', Z
end program scope


This program will not compile because the variable Z in module B has 
been redefined.  If the variable Z in module A came from somewhere 
else, then it would compile and you would have access to both 
variables.  So if you did not know how modules A and B were 
implemented, but only had knowledge of the API for them, you might 
be puzzled why your program does not compile.  This is where I think 
the compiler should be able to print out a list of all the variables 
and where they are declared so that you can understand what is the 
problem.

If you remove the implicit none statement in the above, then the 
program does compile, but the Z that you think you are printing is 
an undeclared local variable, not the Z that is in module B.  So the 
programmer has shot himself in the foot twice, and this is perhaps 
even harder to figure out.  If the compiler could just print out the 
information that it knows, then this would be pretty quick to debug, 
but otherwise it is a problem.  Of course, I recommend using 
implicit none for this and other reasons, but it shows the problems 
that can arise with nested modules.

Here is a version of the above program that renames everything 
according to the nested modules:

module B
   integer :: B_Z=10
end module B

module A
   use B, A_B_Z=>B_Z
end module A

program scope
   use A
   use B
   implicit none
   write(*,*) 'A_B_Z=', A_B_Z
   write(*,*) 'B_Z=', B_Z
end program scope


This program does compile and you have access to the variable in two 
different ways in the main program.  If you change what might appear 
to be one variable, then the other one changes too.  Of course, the 
compiler knows this, this is not a hidden alias, but you the 
programmer might not.  So again, it would be good if the compiler 
could print out this kind of information.

$.02 -Ron Shepard

On Mar 26, 5:47=A0pm, Ron Shepard <ron-shep...@NOSPAM.comcast.net>
wrote:
>
> I agree that there are advantages and disadvantages of the various
> approaches. =A0I happen to like the way fortran did it because it
> scales to large programs better than the other choices without
> unnecessary complications. =A0The largest perl program in existence is
> quite small by fortran standards, so the tradeoffs between namespace
> pollution and simplicity are different.

I'm not sure. Catalyst is more than 20,000 lines, and that's just the
first Perl program that crossed my mind. The SPH program I have in
front of me (in Fortran) is 13,000 lines. I don't know what the
largest Perl program is, but I doubt that it will be "quite small for
Fortran standards".

Also don't forget that Perl is a much more expressive language than
Fortran, and in general it takes fewer lines to say the same thing.
Just like Fortran programs are often more compact than the C/C++
equivalent. Fortran programs might be smaller than C++ programs, but
that's not because there is something wrong with Fortran.

I cannot imagine why *not* having the option to use the module name as
a prefix, as in Perl, somehow makes Fortran scale *better*. That
doesn't make sense to me. Perl's namespace features are almost a
superset of Fortran. It only lacks the renaming feature:

#
# 1. Load a module without merging the namespaces.
#
require Foo;

Foo::bar("hello");

#
# 2. Load a module, pulling all functions into this namespace.
#
use Foo;

bar("hello");


#
# 3. Load a module, pulling in ONLY a couple of functions.
#
use Foo qw(bar biz);

bar("hello");


> In other languages, you would
> need to know all of that in your code and reference the variable as
> A.B.C.D.Z (or something analogous).

I cannot speak for Java or C++, but this is not the case in Perl. It
is not prohibited, but I have never seen a module that does that.


Daniel.

On 3/26/2011 1:25 PM, Daniel Carrera wrote:
....

> I'm not sure. Catalyst is more than 20,000 lines, and that's just the
> first Perl program that crossed my mind. The SPH program I have in
> front of me (in Fortran) is 13,000 lines. I don't know what the
> largest Perl program is, but I doubt that it will be "quite small for
> Fortran standards".

That's _TINY_ for many Fortran simulation codes...

I did an estimate here not terribly long ago that 20k LOC would only be 
about 2% the length of one nuclear design code (for reactor design, not 
military).

I'm aware of at least one geologic well drawdown simulation used in 
oil/gas exploration that's about twice that (or at least was in the 90s 
when last worked w/ the R&D arm of the owner/user of it).

I'm sure the metrological models are every bit as large or larger...

--

On Mar 26, 7:40=A0pm, dpb <n...@non.net> wrote:
> That's _TINY_ for many Fortran simulation codes...
>
> I did an estimate here not terribly long ago that 20k LOC would only be
> about 2% the length of one nuclear design code (for reactor design, not
> military).

Let's not mix up field of application with namespaces. The reason Perl
is not used to write nuclear design codes has little to do with how it
handles namespaces, just like the reason Fortran is not used to write
operating systems has little to do with how Fortran handles
namespaces. The Linux kernel is about 5 million lines and that's very
small compared to Windows. Does this mean that C or C++ can do
namespaces better than Fortran? That's silly. It just shows that
Fortran is not what you use to write operating systems.

Daniel.

On 3/26/2011 2:45 PM, Daniel Carrera wrote:
> On Mar 26, 7:40 pm, dpb<n...@non.net>  wrote:
>> That's _TINY_ for many Fortran simulation codes...
>>
>> I did an estimate here not terribly long ago that 20k LOC would only be
>> about 2% the length of one nuclear design code (for reactor design, not
>> military).
>
> Let's not mix up field of application with namespaces. The reason Perl
> is not used to write nuclear design codes has little to do with how it
> handles namespaces, just like the reason Fortran is not used to write
> operating systems has little to do with how Fortran handles
> namespaces. The Linux kernel is about 5 million lines and that's very
> small compared to Windows. Does this mean that C or C++ can do
> namespaces better than Fortran? That's silly. It just shows that
> Fortran is not what you use to write operating systems.

You were the one who said you thought Perl codes were likely the same 
size as Fortran; not I...

I didn't say a thing about name spaces; I only commented that Fortran 
applications quite commonly are much bigger than your example of "large".

No more, no less...

--

On 3/26/2011 11:40 AM, dpb wrote:
>
> That's _TINY_ for many Fortran simulation codes...
>
> I did an estimate here not terribly long ago that 20k LOC would only be
> about 2% the length of one nuclear design code (for reactor design, not
> military).
>

I think the large size of these Fortran application is because most
were written in F77, and did not take advantage of the
vectorized array and matrix operations and other short cuts
in newer Fortran.

Looking at old Fortran code, one can see lots of long
loops which many could be rewritten now and made much more compact.

Do not judge a program by its size :)

--Nasser

On 3/25/2011 9:25 PM, Nasser M. Abbasi wrote:
> On 3/25/2011 8:19 PM, Gary L. Scott wrote:
>
>>>
>>> I know about ONLY with USE. I've seen it, but that is not
>>> what I am asking.
>>>
>>> USE with ONLY, one lists the variables at the top which
>>> are being used from the module.
>>>
>>> I want to be able to have the module name as part of
>>> the variable, in the code section. Otherwise, each
>>> time one sees a variable, they have to go
>>> to the top and see from which module this variable
>>> came from. Not efficient.
>>>
>>> --Nasser
>
>> Name the variables to be exported from a module with inclusion of the
>> module name or a synonym or shortened version.
>
> Thanks, but this sounds like a hack to me :)
>
> There ought to be a way, in the code, to say
>
> .....
> module_name<>variable_name = 5;
> ....
>
>
> Where <> is the thing I was looking for. Can't use %,
> and can't use '.'
>
> It looks then that there is no such syntax in Fortran.
>
<snip>

OK.  Here's a different hack:

Declare a class in the module, say "mod_class."  Make any variables you 
want to export members of the class.  Define one element of the class, 
say "mod_vars."  When you USE the module, import mod_vars, and refer to 
these variables as "mod_vars%variable_name."  You'd have to do the same 
within the module as well, which might or might not be a problem.  Like 
I said, it's still a hack.  (No, I'm not sure I have the syntax or 
terminology right.)  I have seen this sort of thing done in C to keep 
declarations simpler and to manage what I now know to call namespace issues.

Louis

On 03/27/2011 12:08 AM, dpb wrote:
> On 3/26/2011 2:45 PM, Daniel Carrera wrote:
> You were the one who said you thought Perl codes were likely the same
> size as Fortran; not I...

That is an exaggeration of what I said. I disputed Ron's assertion that 
"the largest Perl program in existence is quite small by Fortran standards".

I don't doubt that Perl programs are overall much smaller than Fortran. 
Perl is extremely popular for very short programs, for example. But 
Ron's assertion seemed like an exaggeration. Especially because he 
attributed the difference to namespaces.


>
> I didn't say a thing about name spaces; I only commented that Fortran
> applications quite commonly are much bigger than your example of "large".


You didn't. Ron did. But you replied to me replying to Ron about namespaces.

In context, Ron was saying that Fortran is more scalable than Perl 
because in Fortran you don't write "foo.bar.biz.something" and in Perl 
you do. I was saying he is wrong. Perl doesn't require that, and Perl 
programs never really do that.


Daniel.

On 3/27/11 1:31 AM, Louis Krupp wrote:
> On 3/25/2011 9:25 PM, Nasser M. Abbasi wrote:
>> On 3/25/2011 8:19 PM, Gary L. Scott wrote:
>>
>>>>
>>>> I know about ONLY with USE. I've seen it, but that is not
>>>> what I am asking.
>>>>
>>>> USE with ONLY, one lists the variables at the top which
>>>> are being used from the module.
>>>>
>>>> I want to be able to have the module name as part of
>>>> the variable, in the code section. Otherwise, each
>>>> time one sees a variable, they have to go
>>>> to the top and see from which module this variable
>>>> came from. Not efficient.
>>>>
>>>> --Nasser
>>
>>> Name the variables to be exported from a module with inclusion of the
>>> module name or a synonym or shortened version.
>>
>> Thanks, but this sounds like a hack to me :)
>>
>> There ought to be a way, in the code, to say
>>
>> .....
>> module_name<>variable_name = 5;
>> ....
>>
>>
>> Where <> is the thing I was looking for. Can't use %,
>> and can't use '.'
>>
>> It looks then that there is no such syntax in Fortran.
>>
> <snip>
>
This is a can of worms ;).  Why do you ONLY worry about variables USEd 
from a module?  Variables in an internal procedure have the same 
problem:  are they local or HOST associated?  Also, variables in a 
module procedure:  are they local to the procedure, local to the module, 
or exported from the module?

Variables aren't the only named things exported from a module; the 
syntax should work for any named entity.

Many modules are merely collector modules that group together related 
modules into one user module.  Something like
        module PDE
           USE  stiff
           USE  elliptical
           ...
        end module PDE
what name should be added to entities USEd from PDE?  Especially since 
both stiff and elliptical are likely to USE BLAS.

If one module has a type which EXTENDS another where does the syntax go 
and which module(s) should it identify?

Dick Hendrickson (perpetual wet blanket)

On 3/27/2011 10:23 AM, Dick Hendrickson wrote:
> On 3/27/11 1:31 AM, Louis Krupp wrote:
>> On 3/25/2011 9:25 PM, Nasser M. Abbasi wrote:
>>> On 3/25/2011 8:19 PM, Gary L. Scott wrote:
>>>
>>>>>
>>>>> I know about ONLY with USE. I've seen it, but that is not
>>>>> what I am asking.
>>>>>
>>>>> USE with ONLY, one lists the variables at the top which
>>>>> are being used from the module.
>>>>>
>>>>> I want to be able to have the module name as part of
>>>>> the variable, in the code section. Otherwise, each
>>>>> time one sees a variable, they have to go
>>>>> to the top and see from which module this variable
>>>>> came from. Not efficient.
>>>>>
>>>>> --Nasser
>>>
>>>> Name the variables to be exported from a module with inclusion of the
>>>> module name or a synonym or shortened version.
>>>
>>> Thanks, but this sounds like a hack to me :)
>>>
>>> There ought to be a way, in the code, to say
>>>
>>> .....
>>> module_name<>variable_name = 5;
>>> ....
>>>
>>>
>>> Where <> is the thing I was looking for. Can't use %,
>>> and can't use '.'
>>>
>>> It looks then that there is no such syntax in Fortran.
>>>
>> <snip>
>>
> This is a can of worms ;). Why do you ONLY worry about variables USEd
> from a module? Variables in an internal procedure have the same problem:
> are they local or HOST associated? Also, variables in a module
> procedure: are they local to the procedure, local to the module, or
> exported from the module?
>
> Variables aren't the only named things exported from a module; the
> syntax should work for any named entity.
>
> Many modules are merely collector modules that group together related
> modules into one user module. Something like
> module PDE
> USE stiff
> USE elliptical
> ...
> end module PDE
> what name should be added to entities USEd from PDE? Especially since
> both stiff and elliptical are likely to USE BLAS.
>
> If one module has a type which EXTENDS another where does the syntax go
> and which module(s) should it identify?
>
> Dick Hendrickson (perpetual wet blanket)

pwb - LOL

In article <immr9l$c6a$1@dont-email.me>,
 Daniel Carrera <daniel@gmail.com> wrote:

> On 03/27/2011 12:08 AM, dpb wrote:
> > On 3/26/2011 2:45 PM, Daniel Carrera wrote:
> > You were the one who said you thought Perl codes were likely the same
> > size as Fortran; not I...
> 
> That is an exaggeration of what I said. I disputed Ron's assertion that 
> "the largest Perl program in existence is quite small by Fortran standards".
> 
> I don't doubt that Perl programs are overall much smaller than Fortran. 
> Perl is extremely popular for very short programs, for example. But 
> Ron's assertion seemed like an exaggeration. Especially because he 
> attributed the difference to namespaces.

Yes, I use perl for short programs all the time. I also use 
Mathematica for short programs, particularly those that involve 
symbolic operations at some point. But I am not fluent in either of 
those languages, I would never consider writing anything substantial 
in either of those languages that I thought fortran was more suited, 
and the namespace problem is one of the reasons.  IMO, it just isn't 
as convenient to write big programs in those languages as it is in 
fortran.

As far as size of code, I think LAPACK is something like 750,000 
lines of fortran code (including both the library itself and the 
testing code that comes with it).  That's 10 to 100 times larger 
than any perl package that has been mentioned, and it is only a 
library, not an entire application.  My own fortran codes that I 
work with daily are about 500,000 lines (not counting LAPACK and 
similar libraries that it uses).  I think the GAUSSIAN electronic 
structure code is well over a million lines of code.  And I expect 
that many of the simulation codes (weather, fluid dynamics, nuclear 
reactor, bomb, geology, etc.) codes are all big packages that might 
be as large as 10^7 lines of code each.  The same goes for CHEMKIN, 
a combined fluid dynamics and chemistry kinetics package, although 
that source code is no longer public domain.  I think Boeing 
simulates their entire airplanes, from engine components to the 
shape of the overhead baggage compartments in fortran - at one time 
you could license their scientific library for your own 
applications.  When you write big codes like this, you pull in all 
kinds of libraries, such as LAPACK, so if you count the lines of 
code in each of those libraries as part of the application, along 
with the application code itself, I expect you could get LOC counts 
as large as 10^8.  It is the modularity of the libraries that allows 
those kinds of large packages to be assembled, and the namespace 
conventions of the language play a large role in how well that 
works.  So yes, a 1000 LOC Mathematica code, or even a 10,000 LOC 
perl script, is a tiny program compared to one of the large fortran 
packages, tiny by several orders of magnitude.

That is why I think this idea of requiring the module name in order 
to access modules variables, A.B.C.D.Z or whatever, just would not 
work in practice.  It exposes too much of the details of the 
low-level implementation to the high-level code.  All the languages 
that are suited for writing big packages have, or at least allow, 
other options that are similar to what fortran does.

Of course, there are also short fortran programs.  You can write a 
one-line hello world program in fortran.  I am certainly not 
claiming that every single perl program in existence is shorter than 
that.  If that is what you thought I meant, then I apologize for not 
being more precise with my language.

$.02 -Ron Shepard

I have several thoughts on this:

1) Neither of us knows enough about Perl programs to say how big the 
largest Perl program in existence is. It is not logical to think that 
because I cannot name a larger Perl program, they must not exist. I 
don't know very many Perl programs. Just a handful. Perl is used in 
Bioinformatics. Maybe they have larger programs, who knows.


2) The length of the largest programs is not a measure of how scalable a 
language is. Perl programs tend to be more compact. In addition, Perl is 
an interpreted language, making it way too slow for the types of 
applications you listed. A simulation code for an air-plane is bound to 
be a large piece of code, and it is bound to be written in a compiled 
language at least for performance. It is wrong to attribute this to the 
*syntax* of the language. Perl is not used for simulations because it is 
way too slow, not because it has a problem with namespaces.


3) Programs in C and C++ can be as large and larger than Fortran 
programs. OpenOffice is over 10 million lines of code. That is just the 
application. It doesn't include libraries. Does this mean that C++ is 
amazing at namespaces? You have been arguing that it isn't.


4) Last, and perhaps most important, Perl *does* *not* require that you 
access module variables with A.B.C.D.Z. The most common way to use Perl 
modules is to pull its functions into the current namespace, and like 
Fortran. You have been arguing that Perl programs are short on the basis 
of an imagined limitation that does not actually exist.


Daniel.



On 03/27/2011 06:56 PM, Ron Shepard wrote:
> Yes, I use perl for short programs all the time. I also use
> Mathematica for short programs, particularly those that involve
> symbolic operations at some point. But I am not fluent in either of
> those languages, I would never consider writing anything substantial
> in either of those languages that I thought fortran was more suited,
> and the namespace problem is one of the reasons.  IMO, it just isn't
> as convenient to write big programs in those languages as it is in
> fortran.
>
> As far as size of code, I think LAPACK is something like 750,000
> lines of fortran code (including both the library itself and the
> testing code that comes with it).  That's 10 to 100 times larger
> than any perl package that has been mentioned, and it is only a
> library, not an entire application.  My own fortran codes that I
> work with daily are about 500,000 lines (not counting LAPACK and
> similar libraries that it uses).  I think the GAUSSIAN electronic
> structure code is well over a million lines of code.  And I expect
> that many of the simulation codes (weather, fluid dynamics, nuclear
> reactor, bomb, geology, etc.) codes are all big packages that might
> be as large as 10^7 lines of code each.  The same goes for CHEMKIN,
> a combined fluid dynamics and chemistry kinetics package, although
> that source code is no longer public domain.  I think Boeing
> simulates their entire airplanes, from engine components to the
> shape of the overhead baggage compartments in fortran - at one time
> you could license their scientific library for your own
> applications.  When you write big codes like this, you pull in all
> kinds of libraries, such as LAPACK, so if you count the lines of
> code in each of those libraries as part of the application, along
> with the application code itself, I expect you could get LOC counts
> as large as 10^8.  It is the modularity of the libraries that allows
> those kinds of large packages to be assembled, and the namespace
> conventions of the language play a large role in how well that
> works.  So yes, a 1000 LOC Mathematica code, or even a 10,000 LOC
> perl script, is a tiny program compared to one of the large fortran
> packages, tiny by several orders of magnitude.
>
> That is why I think this idea of requiring the module name in order
> to access modules variables, A.B.C.D.Z or whatever, just would not
> work in practice.  It exposes too much of the details of the
> low-level implementation to the high-level code.  All the languages
> that are suited for writing big packages have, or at least allow,
> other options that are similar to what fortran does.
>
> Of course, there are also short fortran programs.  You can write a
> one-line hello world program in fortran.  I am certainly not
> claiming that every single perl program in existence is shorter than
> that.  If that is what you thought I meant, then I apologize for not
> being more precise with my language.
>
> $.02 -Ron Shepard

On 3/27/2011 9:56 AM, Ron Shepard wrote:

>
> Yes, I use perl for short programs all the time. I also use
> Mathematica for short programs, particularly those that involve
> symbolic operations at some point. But I am not fluent in either of
> those languages, I would never consider writing anything substantial
> in either of those languages that I thought fortran was more suited,
> and the namespace problem is one of the reasons.  IMO, it just isn't
> as convenient to write big programs in those languages as it is in
> fortran.
>

Mathematica has packages. I write my Mathematica code in packages.
Mathematica packages are like Fortran module.

Wolfram Alpha is written in Mathematica, it is over 5 million
lines of code, may be much more now:

http://blog.wolframalpha.com/2009/05/01/the-secret-behind-the-computational-engine-in-wolframalpha/

"As a result, the five million lines of Mathematica code that make
up Wolfram|Alpha are equivalent to many tens of millions of lines of code
in a lower-level language like C, Java, or Python."

But again, you can't judge something by the size of the program.

I can show you one line of Mathematica code, or even Matlab,
that it would one 30 lines to write an equivalent code in Fortran.
This does not even include any graphics :)

>
> That is why I think this idea of requiring the module name in order
> to access modules variables, A.B.C.D.Z or whatever, just would not
> work in practice.  It exposes too much of the details of the
> low-level implementation to the high-level code.

With all due respect, That is really a ridiculous statement.

For one to make it more clear in the code from which package some
entity was imported, is now exposing too much details? What details?
If the entity is private to start with, then it can't be imported?

You are using that object any way. Writing A.foo() exposes
more internal details than writing foo() ?  How?

Then why not just write

USE all_of_the_modules_in_the_whole_universe;

And now just go on coding. No need to know from which  module
something came from. If you later need to find out from which
module something you are using came from, you go and use
the unix find command and grep command and search for it
on the hard drive.

So, all those languages which allow one (if they choose) to
prefix the module name to the object imported are designed by
idiots who know nothing about software engineering? All modern
languages allows one the _choice_ to prefix the module name or not.

It is a form of documentation of the code.

from  http://www.etse.urv.es/ri/manuals/TutAda/chap15.htm

"The presence of the package name prepended to each subprogram call however,
leads to no ambiguity and therefore follows the basic premise of Ada that a
program is written once but read many times. The extra keystrokes are worth
the trouble to include them.

Use of the use clause is a matter of personal taste or possibly a style
dictated by a project style guide. "

> All the languages
> that are suited for writing big packages have, or at least allow,
> other options that are similar to what fortran does.
>

No. Fortran does not allow the option of prefixing the module name
to the object. That is the whole point.  Other languages give  that
OPTION to the user.

--Nasser

In article <imntvj$6t8$1@dont-email.me>,
 Daniel Carrera <daniel@gmail.com> wrote:

> I have several thoughts on this:
> 
> 1) Neither of us knows enough about Perl programs to say how big the 
> largest Perl program in existence is.[...]

I don't know it with metaphysical certitude, but in a previous post 
you said:

> I don't doubt that Perl programs are overall much smaller than Fortran. 
> Perl is extremely popular for very short programs, for example.

I don't doubt that either.  So I guess I agree with what you said 
then, but I'm not sure what you are saying now.  In any case, 
several fortran programs with 10^6 to 10^7 LOC have been mentioned 
(and there are probably hundreds or thousands of such programs), so 
the fortran namespace conventions certainly do not preclude building 
large programs.

> 2) The length of the largest programs is not a measure of how scalable a 
> language is. [...]

LOC is one of the standard measures of program size.  Of course it 
is difficult to compare languages, which is what we are trying to do 
here, but it is a measure nonetheless.

> 3) Programs in C and C++ can be as large and larger than Fortran 
> programs. 

C at least works the same way as fortran, so that cannot be used as 
evidence that the C approach is better than the fortran approach.  I 
don't know how C++ differs, so I have not mentioned in in any of my 
examples. Others have mentioned the namespace and syntax of C++, 
ada, and java.  Does C++ require A.B.C.D.Z kind of syntax?  If so, 
are you arguing that this enhances the applicability of the language 
for building large programs?

> [...] Does this mean that C++ is 
> amazing at namespaces? You have been arguing that it isn't.

I have not mentioned C++.  I ask again, does C++ require some kind 
of A.B.C.D.Z syntax?  If it does not require it but it allows it 
(like perl), then do you think that the optional A.B.C.D.Z syntax is 
an asset in building large programs?

> 4) Last, and perhaps most important, Perl *does* *not* require that you 
> access module variables with A.B.C.D.Z. The most common way to use Perl 
> modules is to pull its functions into the current namespace, and like 
> Fortran. [...]

Then we agree on the main point.  If that is the "most common way", 
then there is probably a good reason for that.  If perl did require 
that syntax, I think it would be much more difficult to build and 
maintain large programs for the reasons I gave before.

I gave a small example previously showing how variables can be 
named, and renamed, in order to track easily the module in which 
they originate and the chain of module nesting that makes the 
variable visible to the current scoping unit.  Several others also 
mentioned this same programming convention.  That seems to address 
the needs of the original poster in a simple and straightforward 
manner without changing the syntax of the language.  I can't really 
think of any situations in a large program system where that would 
be a good idea, but at least it is possible to do within the current 
syntax of the language.

$.02 -Ron Shepard

On Mar 27, 11:34=A0am, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 3/27/2011 9:56 AM, Ron Shepard wrote:
>
> > All the languages
> > that are suited for writing big packages have, or at least allow,
> > other options that are similar to what fortran does.
>
> No. Fortran does not allow the option of prefixing the module name
> to the object. That is the whole point. =A0Other languages give =A0that
> OPTION to the user.

Fortran does allow one to prefix the module name onto an entity
contained within that module.  It is done with renaming the
entity when you USE the module. You conveniently keep ignoring
this solution for some unknown reason.

--
steve

On 3/27/2011 12:57 PM, steve wrote:

> Fortran does allow one to prefix the module name onto an entity
> contained within that module.  It is done with renaming the
> entity when you USE the module. You conveniently keep ignoring
> this solution for some unknown reason.
>
> --
> steve


Renaming is OK in limited use. But not as a general purpose solution.

http://www.adaic.org/resources/add_content/docs/95style/html/sec_5/5-7-2.html

"# Limit the scope of a renaming declaration to the minimum necessary scope."
"If the renaming facility is abused, the code can be difficult to read."

The language should provide the option to the user, as other languages do.

--Nasser

In article <imo008$2cv$1@speranza.aioe.org>,
 "Nasser M. Abbasi" <nma@12000.org> wrote:

> On 3/27/2011 9:56 AM, Ron Shepard wrote:
> 
> >
> > Yes, I use perl for short programs all the time. I also use
> > Mathematica for short programs, particularly those that involve
> > symbolic operations at some point. But I am not fluent in either of
> > those languages, I would never consider writing anything substantial
> > in either of those languages that I thought fortran was more suited,
> > and the namespace problem is one of the reasons.  IMO, it just isn't
> > as convenient to write big programs in those languages as it is in
> > fortran.
> >
> 
> Mathematica has packages. I write my Mathematica code in packages.
> Mathematica packages are like Fortran module.

Yes, that is the way Mathematica avoids the namespace pollution 
problem.  It uses packages which are like fortran modules.

I usually don't do that, so that is why I have the namespace 
problems I mentioned previously.  BTW, this is the same kind of 
namespace problem that fortran has with contained procedures, and 
those bite me the same way that Mathematica does.

> Wolfram Alpha is written in Mathematica, it is over 5 million
> lines of code, may be much more now:
> 
> http://blog.wolframalpha.com/2009/05/01/the-secret-behind-the-computational-en
> gine-in-wolframalpha/
> 
> "As a result, the five million lines of Mathematica code that make
> up Wolfram|Alpha are equivalent to many tens of millions of lines of code
> in a lower-level language like C, Java, or Python."

It always puzzles me when I see these kinds of claims about 
languages.  In fortran (or C or any other language), you can do 
whatever you want in a single statement:

   call subroutine_to_do_whatever()

You can't get any shorter than a single statement, right?

> But again, you can't judge something by the size of the program.

Yes, for the above reason.

> I can show you one line of Mathematica code, or even Matlab,
> that it would one 30 lines to write an equivalent code in Fortran.
> This does not even include any graphics :)

And visa versa.

> > That is why I think this idea of requiring the module name in order
> > to access modules variables, A.B.C.D.Z or whatever, just would not
> > work in practice.  It exposes too much of the details of the
> > low-level implementation to the high-level code.
> 
> With all due respect, That is really a ridiculous statement.

Ok, explain why.  I gave my arguments for my side, now you give 
yours.

> Then why not just write
> 
> USE all_of_the_modules_in_the_whole_universe;

I do not understand the point you are making here.  We all know why 
you don't want to do that.


> So, all those languages which allow one (if they choose) to
> prefix the module name to the object imported are designed by
> idiots who know nothing about software engineering? All modern
> languages allows one the _choice_ to prefix the module name or not.

Fortran is a modern language that does it differently.  In this 
respect, f90 is about a decade more modern than ada, so the language 
committee had the benefit of hindsight when modules were added to 
the language.  Several posters have described how you can achieve 
this naming convention within fortran.  It is simply a matter of 
naming the variables the way you want them named.

> No. Fortran does not allow the option of prefixing the module name
> to the object. [...]

But you are free to name the variable any way you want.  If you want 
to include the module name, then go ahead and do it.  If you have a 
name conflict with two variables from two different modules, then 
you can rename them in the USE statement to avoid the problem and to 
access both variables.

One thing that you can't do, as far as I know, is to rename the 
module's name.  If you have two modules with the same name, and you 
want to USE both of them, then I don't know how to do that.

$.02 -Ron Shepard

>> "As a result, the five million lines of Mathematica code that make
>> up Wolfram|Alpha are equivalent to many tens of millions of lines of code
>> in a lower-level language like C, Java, or Python."
>

  
> It always puzzles me when I see these kinds of claims about
> languages.  In fortran (or C or any other language), you can do
> whatever you want in a single statement:
>
>     call subroutine_to_do_whatever()
>
> You can't get any shorter than a single statement, right?

Wrong.

We are talking about the ability to solve a given problem using
only the language own syntax, build-in commands and primitives,
which are build into the language.

This mean, for example, in Fortran, using only Fortran build-in
intrinsics, syntax and keywords only. No calls to external user
defined functions.

This is what one means when they say one language is more
'expressive' than another.

New Fortran for example, for me, is more expressive than the
old Fortran, becuase of new synatx added and new intrinsics
so one can solve the same problem  is less code and time.

Enough of this for me today. May be continue this discussion later.

regards,
--Nasser

On Mar 27, 5:08=A0pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 3/27/2011 12:57 PM, steve wrote:
>
> > Fortran does allow one to prefix the module name onto an entity
> > contained within that module. =A0It is done with renaming the
> > entity when you USE the module. You conveniently keep ignoring
> > this solution for some unknown reason.
>
> > --
> > steve
>
> Renaming is OK in limited use. But not as a general purpose solution.
>
> http://www.adaic.org/resources/add_content/docs/95style/html/sec_5/5-...
>
> "# Limit the scope of a renaming declaration to the minimum necessary sco=
pe."
> "If the renaming facility is abused, the code can be difficult to read."
>
> The language should provide the option to the user, as other languages do=
..
>
> --Nasser

Interesting, you started with a specific question, giving an example
for what you were asking, with
>> Any idea what is the right syntax to do what I want?
>>
>> For example, in Ada, I can write   m.z=3D5; where m is a
>> package name, same as Fortran module.

and now (after some people have told the right syntax, explained that
Fortran is not Ada, etc.) you are implying that Fortran has some
problem with renaming and that Fortran should be... different... just
like other languages like Ada, for the reasons given in Ada
documentation. So,
1) Do you really need an answer?
2) Do you want to change Fortran?
3) Both
In case of 1) it's long "many replies" ago. In case of 2) and/or 3)
maybe this is not the right place or, at least, you should make
explicit your ideas since the beginning...

Fernando.
PS: I have my own ideas on some issues in this thread, but I do not
get what the goal of this thread is, that's why I have several
questions and what I think are some related answers.

On 03/27/2011 09:56 PM, Ron Shepard wrote:
> Does C++ require A.B.C.D.Z kind of syntax?  If so,
> are you arguing that this enhances the applicability of the language
> for building large programs?

I have no opinion on whether A.B.C.Z helps or hinders. I only take issue 
with your saying that this is the reason Perl programs are small.

There are reasons why Perl programs are smaller than Fortran programs, 
but namespace handling is not one of them. That's what I want to say. 
Perl's namespace handling does not scale worse than Fortran.

You said Perl programs are small because they use A.B.C.D.Z syntax. That 
is what I dispute. Clearly I have done a poor job at expressing this. 
Perhaps this post will be more clear.

Daniel.

Nasser M. Abbasi <nma@12000.org> wrote:

> On 3/27/2011 9:56 AM, Ron Shepard wrote:

> > That is why I think this idea of requiring the module name in order
> > to access modules variables, A.B.C.D.Z or whatever, just would not
> > work in practice.  It exposes too much of the details of the
> > low-level implementation to the high-level code.
> 
> With all due respect, That is really a ridiculous statement.

Odd, because I think it ridiculous to claim that Ron's statement is
ridiculous. In fact, I think Ron's statement very non-ridiculous.

Why does it seem to me that the most ridiculous statements are often
those claiming that something else is ridiculous? Perhaps for the same
reason that statements preceeded by "with all due respect" often don't
show much.

> For one to make it more clear in the code from which package some
> entity was imported, is now exposing too much details? What details?
> If the entity is private to start with, then it can't be imported?
> 
> You are using that object any way. Writing A.foo() exposes
> more internal details than writing foo() ?  How?

This question suggests to me that perhaps the reason you think Ron's
statement was ridiculous was that you didn't understand it. Note how
your version is not the same as what Ron said. Ron did not say A.foo; he
said A.B.C.D.Z. That is rather majorly different. I am reasonably
confident that the difference was intentional, and indeed was his whole
point (well, anyway, most of it). So when you rephrase in a way that
removes the point, it isn't surprising that you can't see it.

No, A.foo doesn't particularly expose inner details. But A.B.C.D.Z does.
In particular, it exposes that Z not only came from A, but that A got it
from B, which in turn got it from C, which in turn got it from D. That's
quite a lot of inner detail.

For the record, just because I jumped in here with a defense of the
non-ridiculousity (which can't be a real word) of Ron's statement, that
doesn't mean I am necessarily against the having option of qualifying
identifiers with their module name. There is a tendency in these kinds
of debates to assume that anyone who agrees with so much as a single
point made by one side or other must implicitly agree with anything that
was ever said by anyone else on the same side. Tain't so. The *ONLY*
thing I am commenting on is how something like A.B.C.D.Z exposes
implementation details of how Z came to be obtained through A. Yes, I
recognize that qualification with a module name would not necesarily
have to be done that way. That's part of the debate I am not
participating in. I don't consider this thread (or, for that matter,
most newsgroup threads) to be a good way to have a serious discussion of
the merits of such things, either pro or con.

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

On 03/28/2011 12:06 AM, Richard Maine wrote:
> Why does it seem to me that the most ridiculous statements are often
> those claiming that something else is ridiculous? Perhaps for the same
> reason that statements preceeded by "with all due respect" often don't
> show much.

Reminds me of how countries with the word "democratic" in their name 
usually aren't. :-)


> For the record, just because I jumped in here with a defense of the
> non-ridiculousity (which can't be a real word) of Ron's statement, that
> doesn't mean I am necessarily against the having option of qualifying
> identifiers with their module name. There is a tendency in these kinds
> of debates to assume that anyone who agrees with so much as a single
> point made by one side or other must implicitly agree with anything that
> was ever said by anyone else on the same side. Tain't so.

You mean to say that the point of internet forums is not to polarize 
discussion and divide the world into "us" vs "them"? :-)


Daniel.

On 3/27/2011 3:06 PM, Richard Maine wrote:

>
> No, A.foo doesn't particularly expose inner details. But A.B.C.D.Z does.

Then all this Java code written by sun, oracle, and IBM engineers
and others is written but those who do not understand software engineering.

So, when I write

import java.awt.event.ActionEvent;

or

when I write

System.err.println("opps");

I have just exposed the internals structure of the whole
of Java library layout.


One should have just written

USE java.*

and then type

    ActionEvent;

so not to see where ActionEvent is coming from.

OK. Got it.

--Nasser

Daniel Carrera <daniel@gmail.com> wrote:
 
> I have several thoughts on this:
 
> 1) Neither of us knows enough about Perl programs to say how big the 
> largest Perl program in existence is. It is not logical to think that 
> because I cannot name a larger Perl program, they must not exist. I 
> don't know very many Perl programs. Just a handful. Perl is used in 
> Bioinformatics. Maybe they have larger programs, who knows.

I once rewrote some simple bioinformatics Perl programs in C.

The Perl programs, doing very simple processing, ran at about
one megabyte per minute.  First we tried the perl2c program,
but the result was about the same.  In C, I could almost get
1 megabyte/second.  (That was about 10 years ago, so both would
be faster now.)

-- glen

In article <imoeah$712$1@speranza.aioe.org>,
 "Nasser M. Abbasi" <nma@12000.org> wrote:

> On 3/27/2011 3:06 PM, Richard Maine wrote:
> 
> >
> > No, A.foo doesn't particularly expose inner details. But A.B.C.D.Z does.
> 
> Then all this Java code written by sun, oracle, and IBM engineers
> and others is written but those who do not understand software engineering.
> 
> So, when I write
> 
> import java.awt.event.ActionEvent;
> 
> or
> 
> when I write
> 
> System.err.println("opps");
> 
> I have just exposed the internals structure of the whole
> of Java library layout.

With the qualification that I don't know anything about java, here 
is the problem I'm talking about.  Suppose someone reorganizes the 
System module (or whatever it is called), so that ActionEvent is 
defined somewhere else.  Just for an example, suppose it is moved 
around and you now have to access it as 
java.Xawt.Xevent.ActionEvent.  Now, you have to go back and edit 
your program and change all of your old invalid references to the 
new correct ones.  In fact, you might have to go back and change all 
kinds of things because of that internal rearrangement.  What 
happens in Vegas doesn't just stay in Vegas, it now creeps up into 
all of the higher-level user code.

With the fortran approach, the low level modules can be rearranged 
pretty much any way you want, and the higher level code does not 
need to be changed, provided of course that the API really does stay 
the same.  It is that decoupling of the high-level code from the 
details of the low-level modules that makes the software easier to 
maintain, and the difference becomes more significant with more 
levels of nested modules.  It allows one programmer to modify the 
high-level code, and another programmer to modify the low-level 
code, and no incompatibilities need to be introduced at any time.  
The code could keep working during all of the changes at all levels.

BTW, I agree with others that as long as this were implemented in 
fortran in an optional way, and in a way that does not invalidate 20 
years of legacy code, then I would have no problem with this feature 
being introduced into some future fortran revision.  But for the 
reasons I've given in this thread, I just can't see how it would 
help write better code or make existing code easier to maintain.

$.02 -Ron Shepard

On 03/28/2011 09:47 AM, Ron Shepard wrote:
> With the qualification that I don't know anything about java, here
> is the problem I'm talking about.  Suppose someone reorganizes the
> System module (or whatever it is called), so that ActionEvent is
> defined somewhere else.  Just for an example, suppose it is moved
> around and you now have to access it as
> java.Xawt.Xevent.ActionEvent.  Now, you have to go back and edit
> your program and change all of your old invalid references to the
> new correct ones.  In fact, you might have to go back and change all
> kinds of things because of that internal rearrangement.  What
> happens in Vegas doesn't just stay in Vegas, it now creeps up into
> all of the higher-level user code.


Good example. I don't use Java either, but I suspect that the upshot is 
that the Java spec changes slowly in order to keep backwards compatibility.


> BTW, I agree with others that as long as this were implemented in
> fortran in an optional way, and in a way that does not invalidate 20
> years of legacy code, then I would have no problem with this feature
> being introduced into some future fortran revision.  But for the
> reasons I've given in this thread, I just can't see how it would
> help write better code or make existing code easier to maintain.
>
> $.02 -Ron Shepard

I think the feature can be useful in moderation. If I may... I think 
Perl's approach has merit, partly because it already resembles Fortran. 
Suppose module foo has variable z. You could do this:

use foo
print *, z

Or this:

require foo
print *, foo.z


In Perl world, you do see Foo::z, but you rarely see deeper than that. 
One example I am slightly familiar with is the Perl Data Language. When 
you write "use PDL", that imports with hit a whole range of modules that 
you never know about and don't need to know about.

Daniel.

On 03/28/2011 06:48 AM, glen herrmannsfeldt wrote:
> I once rewrote some simple bioinformatics Perl programs in C.
>
> The Perl programs, doing very simple processing, ran at about
> one megabyte per minute.  First we tried the perl2c program,
> but the result was about the same.  In C, I could almost get
> 1 megabyte/second.  (That was about 10 years ago, so both would
> be faster now.)
>
> -- glen

Interesting. I'm not surprised really. Perl is not about speed. Though I 
hear that for regular expressions it is fast.

Question: What was the project? Could it have been done in Fortran? Did 
you try? Just curious.

Daniel.

On 3/27/2011 11:48 PM, glen herrmannsfeldt wrote:
> Daniel Carrera<daniel@gmail.com>  wrote:
>
>> I have several thoughts on this:
>
>> 1) Neither of us knows enough about Perl programs to say how big the
>> largest Perl program in existence is. It is not logical to think that
>> because I cannot name a larger Perl program, they must not exist. I
>> don't know very many Perl programs. Just a handful. Perl is used in
>> Bioinformatics. Maybe they have larger programs, who knows.
>
> I once rewrote some simple bioinformatics Perl programs in C.
>
> The Perl programs, doing very simple processing, ran at about
> one megabyte per minute.  First we tried the perl2c program,
> but the result was about the same.  In C, I could almost get
> 1 megabyte/second.  (That was about 10 years ago, so both would
> be faster now.)
>
> -- glen
I once replaced a hideously complex Perl program with a few Kedit Macros 
and sped it up 100x on a slower CPU than the application ran on.  I 
attempted to speed up the Perl application to match, but couldn't even 
come close.

On 03/28/2011 02:29 PM, Gary L. Scott wrote:
> I once replaced a hideously complex Perl program with a few Kedit Macros
> and sped it up 100x on a slower CPU than the application ran on. I
> attempted to speed up the Perl application to match, but couldn't even
> come close.

Now that is interesting. What did the program do?

Daniel.

On 03/25/2011 10:23 PM, Nasser M. Abbasi wrote:
> Suppose one have module:
> Looked at many examples, but they all just do the global USE
> and then in the code, just use whatever that module exports.
>
> Any idea what is the right syntax to do what I want?

Not sure if this is what you want, but you can do something like this:

1. Write a derived type where you put all the "module variables" as 
member of the derived type. You can make the convention that then name 
of the derived type is similar to the name of the module.

2. Defined an instance of the derived type there in the module with the 
"save" attributes. This way anytime you use it you always use the same 
instance (I guess this is similar to the concept of singleton, or 
"static" in Java).

Borrowing your examples, I'd do something like:

---------- m.f90 ---------
module m_module
   type, public :: m_type
     integer :: z
   end type

   !-- Now instantiate this:
   type(m_type), public, save :: m

--------------

and program that uses the above module:

---------- test_m.f90 ----------
program test_m
use m_module
implicit none
m%z = 5;
end
--------------------

AC

On 03/25/2011 10:23 PM, Nasser M. Abbasi wrote:
> ---------- m.f90 ---------
> module m
>    public
>       integer :: z;
> end module m
> --------------
>
> and program that uses the above module:
>
> ---------- test_m.f90 ----------
> program test_m
> use m
> implicit none
> z = 5;
> end
> --------------------

Not sure if this is what you want, but you can do something like this:

1. Write a derived type where you put all the "module variables" as 
member of the derived type. You can make the convention that then name 
of the derived type is similar to the name of the module.

2. Defined an instance of the derived type there in the module with the 
"save" attributes. This way anytime you use it you always use the same 
instance (I guess this is similar to the concept of singleton, or 
"static" in Java).

Borrowing your examples, I'd do something like:

---------- m.f90 ---------
module m_module
   type, public :: m_type
     integer :: z
   end type

   !-- Now instantiate this:
   type(m_type), public, save :: m

--------------

and program that uses the above module:

---------- test_m.f90 ----------
program test_m
use m_module
implicit none
m%z = 5;
end
--------------------

AC