Print

---

   USE is a means of sharing information.  If a procedure USEs a module,
   that tells the procedure that there are variables, data types, and procedures
   of with certain names over in that module that the procedure migh reference.

The thing in this discussion missing for me is not the USE of a
module, but the design of modules intended to be USEd.  A module
supplies some functionality, implements a contract, provides an API.
In order to do that, a module may have to have a variety of "internal"
pieces of data and procedures.  This is what PUBLIC/PRIVATE helps
with, and it is important for modules intended for general use to be
diligent abut using PUBLIC/PRIVATE.  If that were done, I suspect
there would be less use of ONLY; why gain access only part of an API?
But even then, the choice of public names is important so as not to
cause confusion with like-named concepts in other contracts (e.g. DRAW
a graphical object, or a card from a deck?).  C++ and Java have gone a
bit further than F90 (an F90 module is kind of like a C++/java class
with all static members) with namespaces/packages, with class-name
qualification and with protected inheritance of names.  Yes, sometimes
it gets a little clumsy to qualify, but it does help disambiguate and
avoid name colisions.