Is Fortran going to support Namespace?

21

The Fortran 2003 Handbook (Adams et al) lists the following characters as being part of the Fortran Character set. Note this is expanded from previous editions of the Fortran Character set that only included 53 symbols. Note upper and lower case letters are considered the same.

Letters : ABCDEFGHIJKLMNOPQRSTUVWXYZ

Digits : 0-9
Underscore : _

Special Characters : (space) = + - * / \ ( ) [ ] { } , . : ; ! " % & ~ < > ? ’ ` ^ | $ # @

1 Like
22

Perfect. A useful listing. The symbols that have not been utilized for syntax as of Fortran 2023 (as far as I can recall) are ’ \ { } ~ ` ^ | # '. Someone please correct me if that listing is incorrect, as it is from memory.

23

I have proposed using the curly brackets {} as syntax for implementing true arrays of pointers.

to get around having to imbed them in a derived type. I also think they could be used to implement arrays of deferred length strings.

Character(LEN=:), ALLOCATABLE :: astring {50}

Obviously there are probably “gotcha’s” that would prevent this from working but I’m claiming “ownership” of the curly brackets for these cases just in case :grinning:

1 Like
24

Fortrannic way thus far has generally been to use brackets ( ) as much as possible in the syntax for such situations c.f. the syntax toward SUBMODULEs. My impression is the vendor reps on the standards committee prefer opening and closing brackets, possibly because it makes it simpler to have compatibility with fixed-form source where blanks are insignificant.

Thus it can be something like

   call somesub(somemodule)( arg1, arg2, .. )
..
   b = a + somefunc(somemodule)( x, y, .. )
..

Note though the syntax is really the last on the list of consideration for an ISO IEC standards based approach to introducing features to Fortran. A lot of specific details around the semantics to support namespaces will need to be worked out first. Toward this, one has to understand the full scope of needs and condense and distill them into a use case document.

1 Like
25

The use case for “namespaces” seems pretty narrow, right? It would be useful when…

  1. we want to bring in lots (or all) of the public entities of a module AND
  2. there are too many public names for an only clause to be reasonable AND
  3. there is a reasonable chance of name clashes if we don’t do renaming

Is there another situation that I’ve overlooked? I ask that sincerely, because I have never wished for namespaces in any of the (modest) codes I’ve written. Fortran’s design is already very flexible. We can use a module at either module, subprogram, or block level. We can use only to bring in just the names we need, and we can use renaming to sort out the occasional name clash.

1 Like
27

Renaming can work around all the potential problems that namespaces solve, but they put the burden on the caller and not the callee. For example, if you need to do

use lib_a, only: foo
use lib_b, only: foo

You can change that to

use lib_a, only: foo
use lib_b, only: other_foo => foo

But another part of a potentially huge codebase might use it as

use lib_a, only: other_foo => foo
use lib_b, only: foo

That’s very bad for readability. Namespaces will allow you to use shorter, more consise names when implementing lib_a and lib_b without the above mentioned problems.

4 Likes