Qualify procedure names with module names?

In Python the recommended way to use a Numpy function is to write

import numpy as np

and then prefix the NumPy functions when used, for example np.dot. (Or just import numpy and numpy.dot.) Has something similar been considered for Fortran? One can write

use m, only: foo, bar

instead of just use m, but the reader of a module still needs to look at the top of the module for the relevant use statement to see where an invoked procedure is coming from. Also currently possible is

use m, only: foo => m_foo, bar => m_bar

Would it make sense to allow something like

use m
call m::foo()

so that when an entity from a module is used, its name can be prepended by the module name? If Fortran only had the unadorned use without the only qualifier or the option for renaming, I’d say that optional prepending with the module name would be a necessary feature. But given those capabilities, would the ability to prepend be redundant?


That’s literally the first issue here:

Can you one up it and voice your strong support?

I presented it to the committee, but got lukewarm response. I need more help from the community with issues like these.


This issue also resulted in a proposal:


Thanks for the reference to the proposal. I used :: instead of % because I thought that syntax for a qualified procedure name should differ from that of a type-bound procedure, but I don’t feel strongly about this.

1 Like

I vaguely recall that there was some feedback on this proposal from one of the standards committee meetings, but I couldn’t locate the GitHub thread. I think one of the suggestions was to find more compelling examples of how this would be helpful.

1 Like

Here is the feedback from the committee from the Feb 2020 meeting, summarized by @certik: Namespace for modules · Issue #1 · j3-fortran/fortran_proposals · GitHub

Here are the official meeting minutes: https://j3-fortran.org/doc/year/20/minutes221.txt, though it seems like @certik’s summary in the proposals repo has more details than there are in the minutes.


This needs to be discussed online and at J3/WG-5 meetings over and over for the rest of the committee to warm up to it and so that we get enough feedback to iterate on it.

I think we have a decent shot for this in F202Y. What I think is needed for it to succeed is:

  • Prevalent support for it in the online community
  • Continuous and incrementally revised proposals to J3 on every meeting once we start discussing F202Y
  • Prototype and demo it in a compiler, I think @certik with LFortran is in a good position for this
1 Like

The problem is that in a short code one would use to demonstrate a feature, qualified names don’t seem necessary. I have code such as the one below, and I’d guess others do too, where the reader would like it to be “glance clear” where all the imported entities are coming from, in the lines of code where they are invoked.

program main
use correl_mod        , only: correl
use qsort_mod         , only: unique_sorted
use read_mdy_alloc_mod, only: read_time_series
use get_unit_mod      , only: get_unit_open_file,new_unit,read_words_file
use date_mdy_mod      , only: month_year,date_mdy,write_missing_dates,set_alloc,operator(-),yyyymm,successive_dates, &
use kind_mod          , only: dp
use statistics_mod    , only: mean,sd,print_stats,print_stats_ranges,obs_per_year,stats,sharpe
use util_mod          , only: set_alloc,read_vec_alloc,str,repeat,file_exists,print_time_elapsed,istdout, &
use acf_mod           , only: acf
use gnuplot_mod       , only: plot
use moving_average_mod, only: moving_average
use plot_dates_mod    , only: plot
use interp_dates_mod  , only: interp_dates_values
use read_fund_info_mod, only: fund_info,read_fund_info,match,display
use write_table_dates_mod, only: write_dates_values
use monthly_returns_mod  , only: monthly_returns_from_prices
use write_table_dates_mod, only: write_monthly_table
use seasonal_stats_mod   , only: monthly_stats,write_month_year_stats_matrix
use stats_long_short_mod, only: write_stats_long_short_2_pred
1 Like

@Beliavsky Exactly. I have codes that are much worse than that even. But many times the imported subroutine is only used once or twice, and so calling it via the module name makes a lot of sense.

One of the feedback we got (thanks @milancurcic for posting it!) is to use : instead of %. That is relatively minor. I don’t like %, but used it for consistency.


@certik and everyone interested in this: please also keep this and this in mind.