Namespaces

[certik]

@FortranFan wrote in #86 (comment):

I have long debated in my own mind whether Fortran should formally introduce the concept of NAMESPACEs or whether MODULEs can themselves be elevated to first-class namespaces. Looking at the proposal at #86 and with #1, I'm presently inclined toward the former.

Whilst I don't quite have a list of the requirements and specifications necessary toward an initial proposal, a sketch of the idea is to include either a new NAMESPACE scope and/or NAMESPACE attribute to MODULEs in addition to PUBLIC/PRIVATE visibility of MODULEs in a NAMESPACE. Then a given NAMESPACE can IMPORT other NAMESPACEs. Fortran can formally define a GLOBAL namespace and state all EXTERNAL MODULEs (a la external procedures) in a program are part of this namespace. The language can then have some rules for name qualification and aliasing. Code then might look like the following with illustrative syntax:

namespace my_lib
   public module constants
      real, parameter :: PI = 3.14
   end module
   private module utils !<-- can be USE'd only by modules in the same namespace
      interface
         module subroutine draw()
         end subroutine
      end interface
   end module
end namespace

namespace my_lib !<-- A namespace can be extended with more modules
   public module solver
      use constants, only : PI !<-- It can USE modules from the same namespace
   contains
      function calcradius( a ) result( r )
         real, intent(in) :: a
         result :: r
         r = sqrt(a/PI)
      end function
   end module
end namespace

namespace global !<- optional, for 'global' namespace will exist by default
   import my_lib, only : constants, solver ! import 'public' modules only from another namespace
   program p !<-- A program unit can only be part of GLOBAL namespace
      use constants, only : PI !<-- does not 'clash' with my_lib::constants
      real :: area
      print *, "PI = ", PI !<-- PI from USE-associated 'constants' module 
      area = 100.0
      associate ( PI => my_lib::constants%PI, calcrad => my_lib::solver%calcradius )
         print *, "circumference = ", 2.0*PI*calcrad(area)
      end associate
   end program
end namespace

Note the above is based on the use cases in #1 and #86; once more use cases are brought to light, it might help refine the idea of a NAMESPACE.

[Leonard-Reuter]

I can't decide yet, whether I prefer this over the 'module elevation'.

Til I can, one remark: if you add Fortran after the three ` that begin the code section, you get Fortran syntax highlighting =)

[certik]

@libavius the above quote has fortran-modern after ```. The issue with just fortran is that GitHub colors it incorrectly, because it doesn't understand this proposed syntax, as it is not a standard Fortran syntax yet.

[FortranFan]

A thought I've been carrying once the work toward fpm commenced and how well fpm has been received is the notion of a formal language construct that itself can demarcate a package (or an assembly). Especially how it can help make it viable for objects to be consumed across MODULEs readily within such a construct but not externally.

Such a formal construct (say a package) can open up the notion of an "internal" entity that is USE'able within that construct but not externally to it. This can help greatly relative to the current limitations of PUBLIC/PRIVATE visibility of entities in MODULEs.

Thus one can include some of the characteristics that namespaces tend to offer (such as in C++ and those "inspired" by it). But not be constrained by that concept which is now in common parlance in much of computer science literature but which is not without limitations.

That is, the facility that ultimately comes about in Fortran can be "Fortranesque" when it comes to serving the practical needs of practitioners and not carry the "baggage" of familiarity and resultant expectations with namespaces.

[FortranFan]

With respect to the original post here toward the proposal for a "proper" NAMESPACE facility in Fortran and given also discussions on this forum (#218) and some recent debates elsewhere toward allowing new practitioners of Fortran to move beyond the implicit mapping scheme, I thought I will post a thought I have long had and perhaps a reader or more might get interested in it and develop it into an idea that might lead eventually to a proposal.

The thought is this:

• make implicit none the default in NAMESPACEs and develop proper scoping rules for all the program units that are enclosed in a NAMESPACE to have by default the same implicit mapping scheme as the enclosing NAMESPACE.

So refer to the original post to review the proposal on "proper" NAMESPACEs:

• say a namespace n encloses module m. Then the default implicit mapping in module m shall be that corresponding to implicit none.
• if there is interest and value in this, then the NAMESPACEs shall support IMPLICIT statements, say implicit integer(i-n), real(a-h, o-z) in which case all the modules in that NAMESPACE shall have the same implicit mapping as what is currently in the standard.

To reiterate,

namespace n
   ! `implicit none` is the default
   module m
      ! "inherits" the default `implicit none` setting from enclosing scope which is the `NAMESPACE`
      ..
   end module m
   ..
end namespace

Please note also another thought is to support semantics and syntax somewhat like submodules to permit "free-standing" modules:

namespace(n) module m
   ..
end module

Depending on the feedback of compiler developers, the NAMESPACE may need to list the enclosed modules:

namespace n
   module m
   module o
   ...
end namespace

With a "proper" NAMESPACE facility, a bit of a feedback I have is the codes of interest to a couple of possible large teams who are considering big, new, production codes for simulations with components also possibly in modern Fortran will be very open to enclosing all the Fortran modules in namespaces and thus having implicit none the default will allow all such modules to "inherit" without having to explicitly override the implicit mapping rules in the standard for other program units.

[FortranFan]

With respect to the original post here toward the proposal for a "proper" NAMESPACE facility in Fortran and given also discussions on this forum (#78) and requests elsewhere regarding the default kind of constants (and perhaps) intrinsics, the thought also is the NAMESPACE to be able to define such defaults and to have all the enclosing modules to "inherit" the defaults:

namespace n
    default real ( kind=selected_real_kind( p=12 ) )
    ..
    module m
    ..
end namespace
namespace(n) module m
    ! the default kind of real literal constants shall be the one defined in the enclosing module which has a precision of 12
    ..
end module

[klausler]

Namespaces are a concept for managing names, not a vehicle for semantic changes to typing.

[FortranFan]

Namespaces are a concept for managing names, not a vehicle for semantic changes to typing.

Agreed if one wants to be too theoretical about it but

a) in the context of Fortran and considering its long, very practical legacy, extending the notion of namespaces to define certain common properties that apply to the contents of names that it manages is alright,

still if the term is an issue then
b) consider modules in Fortran currently which do serve somewhat as namespaces even as modules can mean different things in different languages. Instead of NAMESPACE then, if there is a better term (supermodule, package, assembly, foo, whatever), that helps provide the practitioners of Fortran with the kind of facilities in the original post and in my last 2 comments above, that will be fine.