Is Fortran going to support Namespace?

1

I recently briefly checked some Julia books such as,

Anyway, this book again reminds me that, believe it or not, Julia and Fortran are more or less competing in some way, and it is happening, with or without you and me. Fortran is very good, but perhaps need to absorb some good ideas from other language as quick as possible.

For example, in Julia, there is something called Namespace. So one can define, eg, the same name of variable/function/subroutine called func in both module AAA and BBB. When use func, one just need to do module_name.func like below,

AAA.func
BBB.func

I know in Fortran there is no such thing, but can do some => aliasing trick,

But the idea of Namespace seems to be very convenient and useful.

Just curious, is there plan that this feature could be added to Fortran in the nearest future?

5 Likes
2

@certik just opened up a thread to discuss new ideas for Fortran 202Y

You can make your suggestion there. :+1:

3 Likes
3

It’s being discussed here at least: Namespace for modules · Issue #1 · j3-fortran/fortran_proposals · GitHub

Namespaces are very useful for keeping code organized in large projects. I would definitely welcome such a feature.

4 Likes
4

Previous discussion from Sep 2021:

2 Likes
5

As @plevold said, that is literally the issue number 1 in our proposal list, as it was the first thing people suggested to me Fortran should have. As you can see, it is upvoted a lot. @CRquantum and others if you like it, please upvote it as well.

3 Likes
6

Namespacing would help me clean up so much legacy code. Perhaps instead of use somemodule, something like access somemodule could give access to somemodule's members via somemodule.somefunction()

4 Likes
7

The use of a new keyword/statement seems promising. Earlier discussions seemed to focus more on possible additions to the existing use statement, but all seemed a bit more clumsy. Note that the use of . as the separator is probably troublesome due to the existing user defined operator semantics (i.e. something.dot.otherthing). I’ve seen some suggestions that maybe it’s still workable, but it’s probably easy enough to pick a different symbol/ligature; -> perhaps?

5 Likes
8

Whats your opinion concerning the realtionship between the existing use and the new access statements.

For example let us assume a module mymod containg the variables a, b, c.

should

subroutine usemod

use mymod, only: a
access mymod

print *, a+ mymod.a / mymod.b

end subroutine mymod

be possible?

1 Like
9

Or instead of

AAA.func

may be can try to use @

func@AAA

Is @ symbol defined in Fortran?

1 Like
10

Thank you very much @certik , I upvoted for it,

image
image1862Ă—1111 175 KB

Now it got 22 upvote, hopefully we get more upvotes and make it come true :+1:

2 Likes
11

The @ notation is close to the use in natural language, but might feel a bit exotic for programmers that are used that the whole (module, object ect…) is first, followed by the part.

2 Likes
12

Maybe just a silly idea of mine, but could, in principle, the tile sign ~ be used?

1 Like
13

Another idea would be to use the :: operator like C++ .

Pro: looks familiar to a lot of people working in computational science

Con: Already used in Fortran for variable declaration

1 Like
14

How about let Fortran leading the fashion this time by using @ ? :nerd_face: :laughing: :slight_smile:

1 Like
15

I don’t think that’s a problem, and I think there are already situations allowed by the standard where such aliasing can occur. However, the onus is on the programmer not to alias actual arguments through dummy arguments. I.e.

use mod, only: b => a
use mod, only: c => a

call swap(b, c)

is technically not standards conforming, but compilers are not required to (and in many instances can’t) check for it.

1 Like
16

We just used the @ symbol for rank agnostic array section denotation (or something like that). It’s coming in the next standard. I’m not quite clear whether that would preclude it’s use for this purpose though.

1 Like
17

Maybe? I believe that the current standard is limited to the original ASCII character set, of which ~ is not a member. But I may be incorrect on either of those, and it may be possible to expand that set. It would require a bit of background research.

2 Likes
18

Note, however, that a programmer who accesses a single module variable by more than one name could be asking for trouble. Consider

module mod
implicit none
integer a
end module

program pgm
use mod, b => a, c => a  ! don't do this!
implicit none
b = 4
c = 7
print *,b,c
end program

The potential for error is easy to spot here, but if the assignments to b and c are separated by many lines of code, …

3 Likes
19

@everythingfunctional , do you mean the original Fortran character set or the original ASCII (ISO 646) character set. Tilde is part of ISO 646 but is one of those characters that are reserved for “national use” which means its ASCII value (126) might be a different symbol in other countries. I doubt that the standard is restricted to the original Fortran character set since the square bracket [ is not included in that character set.

3 Likes
20

I’m honestly not clear on the details. It was more just a vague recollection of something I heard when discussing the use of the @ symbol for a feature in the upcoming standard. I thought I heard somebody say we were running out of available symbols, and listed off the ones we hadn’t used. I don’t believe ~ was among them. If somebody wants to investigate what exactly is available in the Fortran character set and what symbols are left unused I would be interested to hear it.