# Why do we need TYPEOF? **URL:** \ **Category:** Language enhancement\ **Created:** [March 22, 2025, 6:13pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454 "2025-03-22T18:13:47Z")\ **Posts on this page:** 13\ **Page:** 4
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [April 2, 2025, 2:08pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/63 "2025-04-02T14:08:46Z")
> [@jwmwalrus](#): > > ```auto > implicit none > > print*,c_m %% a_m %% dummy > print*,c_m %% dummy ! comes from b_m > print*,c_m %% another_val > end > > ``` Not pretty, but indeed I can’t see how name collisions can occur. ---
**Author:** ![Jcollins](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jcollins/32/540_2.png) [@Jcollins](https://fortran-lang.discourse.group/u/Jcollins)\ **Post date:** [April 2, 2025, 6:58pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/64 "2025-04-02T18:58:28Z")
Sorry for the delay - at a funeral. Directory structure: ├── build │ └── build.sh ├── main │ └── write\_colours.f90 ├── module\_1 │ ├── colours.f90 │ └── m\_car\_1.f90 └── module\_2 ├── colours.f90 └── m\_car\_2.f90 main/write\_colours.f90 PROGRAM write\_colours ``` USE m_car_1 USE m_car_2 CALL car_colour_1 CALL car_colour_2 ``` END PROGRAM write\_colours ! \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* module\_1/colours.f90 MODULE m\_colour ``` CHARACTER(LEN=*),PARAMETER :: car_colour = "red" ``` END MODULE m\_colour ! \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* module\_1/m\_car\_1.f90 MODULE m\_car\_1 ``` USE m_colour CONTAINS SUBROUTINE car_colour_1 WRITE(*,'("Car colour is: ",A)')car_colour END SUBROUTINE car_colour_1 ``` END MODULE m\_car\_1 ! \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* module\_2/colours.f90 MODULE m\_colour ``` CHARACTER(LEN=*),PARAMETER :: car_colour = "blue" ``` END MODULE m\_colour ! \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* module\_2/m\_car\_2.f90 MODULE m\_car\_2 ``` USE m_colour CONTAINS SUBROUTINE car_colour_2 WRITE(*,'("Car colour is: ",A)')car_colour END SUBROUTINE car_colour_2 ``` END MODULE m\_car\_2 ! \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* build/build.sh #!/bin/bash # build.sh gfortran -c ../module\_1/colours.f90 gfortran -c ../module\_1/m\_car\_1.f90 gfortran -c ../module\_2/colours.f90 gfortran -c ../module\_2/m\_car\_2.f90 gfortran -c ../main/write\_colours.f90 gfortran -o write\_colours.exe \*.o # End of build.sh Output: Car colour is: red Car colour is: blue So we have two different modules named m\_colour in the same program. Didn’t even need to use libraries, though that is how it usually happens. Not standard conforming, but the compiler and linker can’t know. Who designed this language? BTW also works with colors 🤨 ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [April 2, 2025, 7:32pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/65 "2025-04-02T19:32:46Z")
Ah I see — using the same module name twice. But that seems unrelated (orthogonal) to the “namespace for modules” feature? ---
**Author:** ![Jcollins](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jcollins/32/540_2.png) [@Jcollins](https://fortran-lang.discourse.group/u/Jcollins)\ **Post date:** [April 2, 2025, 8:27pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/66 "2025-04-02T20:27:04Z")
I don’t think so. If the module name is passed down to the users a collision will occur? ---
**Author:** ![MarDie](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mardie/32/54_2.png) [@MarDie](https://fortran-lang.discourse.group/u/MarDie)\ **Post date:** [April 2, 2025, 8:47pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/67 "2025-04-02T20:47:18Z")
For the following code, gfortran gives an error ```auto module a implicit none integer, parameter :: one = 1 end module a module b implicit none integer, parameter :: one = 2 end module b ``` ```auto program f use :: a use :: b implicit none print*, one end program f ``` which is a what I expect. The same should happen for repeated module names. It needs to be fixed, either by renaming one of the module names (possible only for own code) or by importing with an alias. Something like ```auto use, namespace :: a_m => x_m ``` From my shallow understanding, Python modules behave exactly as what is shown in [Why do we need TYPEOF? - #57 by jwmwalrus](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/57) and I’m not aware of any severe issues. I could imagine that submodules increase the complexity. Does Lfortran support them already @certik? That would be worth some prototyping to figure out whether (nested) submodules should reside in the namespace of the host module or introduce their own namespace. Edit: I just had a look at the proposal (J3/25-119r1) and I find it pretty weak. It leaves the impression that namespaces are mainly to prevent name clashes. That is one aspect, but for me namespaces are a way to understand dependencies between different entities, i.e. modules. Also, the solution to prefix functions/subroutines with the module name (e.g. module `math` has functions like `math%cos`) is not really satisfactory because that “blocks” the underscore for other use cases. Is `math_true_divide` a function `divide` from `math_true` or `true_divide` from `math`? ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [April 2, 2025, 8:55pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/68 "2025-04-02T20:55:51Z")
> [@Jcollins](#): > > So we have two different modules named m\_colour in the same program. Didn’t even need to use libraries, though that is how it usually happens. Not standard conforming, but the compiler and linker can’t know. Who designed this language? There are many examples of non conforming codes that a compiler cannot detect, and not only in Fortran. In this case, even the linker is fooled because an object file is overwritten by another one. What I’d rather like to see is an example of conforming code that would break if namespaces were introduced. ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [April 2, 2025, 11:05pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/69 "2025-04-02T23:05:07Z")
> [@MarDie](#): > > I could imagine that submodules increase the complexity. Does Lfortran support them already @certik? That would be worth some prototyping to figure out whether (nested) submodules should reside in the namespace of the host module or introduce their own namespace. We don’t yet. If there are an issues, we just need to resolve them. (The submodules go exactly the other way than Python nested modules, I personally prefer the Python approach, but that’s a separate issue.) So far I am not aware of any issues that can’t be quite easily resolved. But let’s bring actual code and we’ll tackle it with actual code and compiler implementation, that settles everything. ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [April 3, 2025, 12:12am UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/71 "2025-04-03T00:12:10Z")
> [@MarDie](#): > > I could imagine that submodules increase the complexity. In regards to the namespaces feature, they shouldn’t; the namespace should allow access to public entities only. A submodule entity is only visible to the `ancestor-module` if it has an interface declared for it in said module (and `interface` means `procedures only`). For example, if you declare a derived type in a submodule, an `ancestor-module` is unaware of such declaration (and therefore, it can never be made public). Something similar happens with submodules of submodules. Only the linker needs to make sense of what’s there and what’s missing. (The gfortran implementation of submodules is messed up in regards to entity access and what the linker sees, but that’s a different thing) ---
**Author:** ![MarDie](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mardie/32/54_2.png) [@MarDie](https://fortran-lang.discourse.group/u/MarDie)\ **Post date:** [April 3, 2025, 7:48am UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/72 "2025-04-03T07:48:03Z")
> [@jwmwalrus](#): > > In regards to the namespaces feature, they shouldn’t; the namespace should allow access to public entities only. I agree, that is how submodules behave outside of the ancestor module. But what to do within a module that has nested submodules? Maybe some namespacing would be helpful there as well to know where exactly something is defined. As far as I know, submodules are a unique feature of Fortran so there are no lessons learned from other languages. I therefore agree with @certik that one needs a prototype and I also agree with the fact that submodules are not considered for the upcoming standard because of the lack of experience. Otherwise, we get `use, namespace :: a_m` in 2028 and `use, namespaced :: a_m` in 2031. That happened with `enum` and `enumeration`. By the way, if I understand it correctly the traditional way of agreeing on a Fortran standard was the formalization of vendor-specific extensions that turned out to be useful. That is more or less the same as having prototypes, just that there is an upfront discussion on how the extension should look like. ---
**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\ **Post date:** [April 3, 2025, 8:58am UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/73 "2025-04-03T08:58:15Z")
> [@MarDie](#): > > As far as I know, submodules are a unique feature of Fortran But what do you buy as a gift for Ada, the language that has everything? 🙂 —i.e., Fortran submodules were likely modeled after Ada’s “package bodies”, so that’s the precedence. ---
**Author:** ![Jcollins](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jcollins/32/540_2.png) [@Jcollins](https://fortran-lang.discourse.group/u/Jcollins)\ **Post date:** [April 3, 2025, 11:13am UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/74 "2025-04-03T11:13:40Z")
The point of making the little example was to show that putting the module name into the namespace can cause a problem - this was @certik 's question. It is actually very unlikely that this could happen in real code. Duplicate module names usually occur because modules with the same name are accessed in different libraries. In this case the linker never sees the namespace and nothing will go wrong. It is a problem for us, and I assume for Polyhedon (Plusfort/spag), Understand for Fortran, Codee etc. We can’t (yet) process the source code of programs which contain duplicate modules. Working on it! ---
**Author:** ![cmaapic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/cmaapic/32/659_2.png) [@cmaapic](https://fortran-lang.discourse.group/u/cmaapic)\ **Post date:** [April 3, 2025, 2:40pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/75 "2025-04-03T14:40:35Z")
I thought that they came from Modula 2. In Modula 2 modules have a definition component and an implementation component. This allows the decoupling of interface from implementation. Here is an extract from the next draft standard. 8 3 A submodule may provide implementations for separate module procedures (15.6.2.5), each of which is 9 declared (15.4.3.2)within that submodule or one of its ancestors, and declarations and de􀏐initions of other 10 entities that are accessible by host association in its descendants. ---
**Author:** ![wspector](https://avatars.discourse-cdn.com/v4/letter/w/47e85d/32.png) [@wspector](https://fortran-lang.discourse.group/u/wspector)\ **Post date:** [April 3, 2025, 7:03pm UTC](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/76 "2025-04-03T19:03:02Z")
> [@cmaapic](#): > > I thought that they came from Modula 2. In Modula 2 modules have a definition component and an implementation component. This allows the decoupling of interface from implementation. Here is an extract from the next draft standard. Modula and Ada were (late '70s/early '80s) contemporaries. I know someone who worked behind the scenes on Ada, and could ask him. I suspect that at least in the case of Ada, it was influenced by the COMPOOLs in JOVIAL - since JOVIAL was one of the DOD languages Ada was supposed to replace. [Previous page](https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454.md?page=3)