Namespace for modules #1
Comments
|
The paper is submitted at https://j3-fortran.org/doc/year/19/19-246.txt. I will try to get feedback on it from the committee. CC @zingale. |
certik
added
under consideration
|
Agree, this seems like a good feature. |
|
So the committee unfortunately did not consider this proposal at the meeting last week. I was hoping to get at least a general "yes" or "no" direction from the committee. But I talked to a few members directly, and I did not hear any "this is a bad idea", or "this should not be done". Here is my plan:
|
|
@septcolor that's a valid concern. My plan to overcome this is to use this github repository to get support for proposals. If the Fortran community puts thumbs up for a proposal, or otherwise expresses strong interest, then relatively to other ideas proposed here it will be obvious which proposals are high priority, and which are low priority. And then it will be easier to argue for a particular proposal at the committee. |
|
Fyi a new thread at comp.lang.fortran inquiring of a missing feature in current Fortran which can be met by the proposal here: By the way, I had a similar interest along the lines of this proposal several years ago: |
|
Thanks @FortranFan. This is one of the popular issues in here and I am going to insist for the committee to consider it at the next meeting. However, I welcome any help with improving the current proposal (linked above). |
|
@certik wrote:
@certik and others interested in this, if you haven't already please take a note of comments online, especially by Ian Harvey at comp.lang.fortran such as this one: Look at the last 3 questions in that comment: addressing these questions suitably will strengthen the proposal. Some aspects that come to my mind with these questions include:
|
|
@FortranFan thanks a lot for pointing these potential issues out. Let's address them. |
|
I think calling DRY good and WET bad is rather arbitrary and not a good
argument. More explicit programming can help avoid some mistakes. In python
I prefer importing explicitly all names that I use in the code I write. If
I feel lazy or only do fast prototyping I import the whole module.
I don't see the discussed feature as necessary but that's because I
probably will not use it. But for those who prefer that programming style
it might be good to have that option.
Dominik
pon., 18 lis 2019, 18:19 użytkownik septcolor <[email protected]>
napisał:
… As for why a more explicit namespace control is useful (and so commonly
used by other languages), I think there may be at least several reasons:
- Minimize the degree of symbol/name contamination in the current scope
- Enhance the readability of a code via explicit qualifiers (no need
to search for
"where this variable comes from")
- DRY (don't repeat yourself)
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
- Potentially benefit from a convenient feature for code completion by
modern editors and IDEs (e.g. "Intellisense"
https://docs.microsoft.com/en-us/visualstudio/ide/using-intellisense?view=vs-2019
)
------------------------------
Reference a module like a global "object"
In object-oriented (OO) programing, we know that it is very convenient to
have the ability to refer to components and TBP via the "%" symbol. What we
want is close to this ability for a module, such that we can reference an
entire module as a global object (like "singleton"). We could mimic its
behavior by creating a dummy type that provides aliases to all module
variables and contained routines (e.g., via pointers and TBP with NOPASS),
but this approach is sometimes rather tedious and may not be
straightforward for 3rd-party libraries. I think this kind of extra work
becomes unnecessary when a qualifier-based module access is provided at the
language level.
------------------------------
About DRY vs WET
The DRY Wiki page mentions WET as an anti-pattern (i.e., not good
practice), e.g. "write everything twice" and "we enjoy typing". To import a
routine with a long name, I have to type it twice in current Fortran (i.e.,
once for a USE statement and once for actuall CALL statement). I often find
this frustrating when I need to import many routines with long names.
Sometimes, it is suggested to use the rename facility of USE (e.g., use
foo_mod, only: shortname => long_routine_name), but I feel this approach
is often not ideal because of the need to consider yet another name for
each imported routine and also because the reader needs to search for their
local definition at the top of the current scope.
------------------------------
Matplotlib may be a good "use case" of an explicit qualifier (mpl, plt,
etc)
I think a good "real-world" use case may be Python/matplotlib, which
commonly use the qualifier "mpl", "plt", and so on. Because Matplotlib
contains tons of names/symbols inside, it is clearly not good practice to
import all symbols at the same time (via star import). On the other hand,
if Python had only Fortran-like import facility, it would have to type
every routine names twice, which is very tedious and lengthy in practice.
In addition to the case of Lapack and redundantly named routines (as
described in https://j3-fortran.org/doc/year/19/19-246.txt),
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1?email_source=notifications&email_token=AC4NA3IACAIES5ITFULEN3LQULFB5A5CNFSM4JBFRGNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEELG26Q#issuecomment-555117946>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4NA3IAD5NPU5VPGKDAU3TQULFB5ANCNFSM4JBFRGNA>
.
|
|
Gets my vote FWIW. I have wanted this for some time, without knowing its name was "namespaces". |
|
@qolin1 I just called it "namespaces" for a lack of a better name. We will keep pushing for this at our next committee meeting. I think this is a popular feature. |
|
I would personally deem this low priority too.
pon., 23 gru 2019, 18:00 użytkownik Peter Klausler <[email protected]>
napisał:
… @qolin1 <https://github.com/qolin1> I just called it "namespaces" for a
lack of a better name. We will keep pushing for this at our next committee
meeting. I think this is a popular feature.
But we need to prioritize. This change is a convenience, not a fix or an
enabling feature.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1?email_source=notifications&email_token=AC4NA3LKUEOVUQP4OQOAL5TQ2DVEJA5CNFSM4JBFRGNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHRQP5Y#issuecomment-568526839>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4NA3PAMUL3LSMMTI42HE3Q2DVEJANCNFSM4JBFRGNA>
.
|
|
@klausler, @gronki make sure you put thumbs up on issues that you find high priority, and let's collaborate on the top priority issues. I just created #122 for that purpose, let's discuss the list of top priority issues there. Regarding this issue #1, for me personally this is a huge quality of life improvement, that is a relatively simple feature, and yet it allows to use Fortran modules more like Python. How this stacks up against some other features that we want to push in terms of prioity, that's for a discussion to be had at #122. |
|
|
I like the idea of namespaces, and I like @jme52 syntax example, @jme52 , Why do you think using |
Indeed, once you can namespace, simple and common names will proliferate in modules and the user should have a way to not have them pollute the global namespace. |
|
@klausler That seems to be a very similar idea to what I proposed above #1 (comment), but I thought you didn't like it. Are you proposing exactly the table in that comment, or are you proposing the following table (in other words, do you want to allow
Furthermore, in all cases 1.-5., the module name If the above is what you are proposing, I can see all kinds of extensions in the compiler, for example with an option the compiler can start warning (by supplying |
|
Ok, so to summarize, you are proposing this:
Where the cases 1. and 2. are exactly equivalent to Python, but cases 3., 4. and 5. are a "superset" of Python: they import the I like this proposal. |
|
Thanks Peter. My goal is to get it pre-approved by the committee, saying "yes, we want this feature, as long as all the issues can be satisfactorily resolved". The minute it does, I am sure multiple people from the community will help. Obviously nobody wants to put in weeks of work if the committee decides they don't want this feature in the first place. I plan to prototype this in a compiler. |
|
@klausler wrote Oct. 1, 2020 6:48 PM EDT:
I agree. As I alluded to earlier, Fortran language can do better by gaining the formal concept of namespaces. Ideally, features such as this are best handled as part of that effort. Considering the complexities and constraints involved with piecemeal attempts, a prototype implementation for the formal namespace concept itself will be nice. The aspects such as this thread can be subparts of such an initiative. |
|
I personally feel we don't need namespaces, but I agree with Vipul that we should keep it in mind and not close doors by introducing something that would make it very hard to introduce namespaces later if the community wishes that. Modules and a well designed "import" is what I personally would like to see. Fortran is very close. @septcolor regarding who can contribute: I strongly encourage you and anyone else to contribute. The committee and the community is composed of both users and compiler vendors / experts, and we need both to collaborate on new features. Leaving things just to compiler vendors, or just to users to design is not optimal, we need a healthy collaboration of both groups. |
|
@wclodius2 wrote Oct. 1, 2020
If there are folks who aren't enthused by any of the keywords thus far, here's another one that can perhaps considered for the poll? use, prefix(ut) :: utils, only : savetxt
..
call utXsavetxt(..) |
|
I think, the idea with |
I would find it rather confusing, not the first one, which I think is neat, but the second: "as is" makes me think about "as given" / "raw" / "as provided", so equivalent to the current behavior with What about
instead? I find it very "natural-english-alike", which is imo what Fortran has always striven for... |
|
How about |
I think, that would be quite Fortranic and nice, I like it a lot! Only, I'd rather go with an adjecive ( |
|
Maybe prefixed, namespaced does not look that much like english :) |
|
Does this usage case help motivate the namespace proposal? I have a clash between a dummy argument name and a typename. module object_module
type :: object
end type
contains
subroutine handle_object(object)
class(*), intent(in) :: object
select type(object) ! the variable
type is (object) ! the typename
! do something
end select
end subroutine
end moduleTo resolve the name clash, I have the following options
module object_m
implicit none
type :: object
end type
interface
module subroutine handle_object(object)
class(*), intent(in) :: object
end subroutine
end interface
end module
module rename_object
use object_m, only: object_m_object => object
public
end module
submodule (object_m) object_impl
contains
module subroutine handle_object(object)
use rename_object
class(*), intent(in) :: object
select type(object)
type is (integer)
print *, object
type is (object_m_object)
! ...
end select
end subroutine
end submoduleSolution 3 is not very desirable because I suddenly have a new module, just to rename a type. It would be much nicer to just to |
|
This was put on the feature list for F202Y. But then it was dropped in https://j3-fortran.org/doc/year/25/25-119r1.txt. |
It was not necessarily dropped, but the initial plan for an implementation was decided to not be ideal. During the discussion it was suggested that maybe a new construct would be a way to go. Something like A namespace would then be a first class entity. So we don't know what the feature will look like yet, but it wasn't dropped from the work list (WG5 has to do that). |
|
Thanks @everythingfunctional for the feedback. The main objection seems to be:
Do you understand what exactly the issue is here? Yes, one “passes” implicitly the module name into nested scopes, just like in Python. What exactly is the incompatibility? If you declare a local variable of the same name as the module, it will shadow it. (I also asked here: https://fortran-lang.discourse.group/t/why-do-we-need-typeof/9454/56.) |
Except that currently transitive module names are not implicitly brought into scope by a module a
end module
module b
use module a
end module
use module b
integer a
end |
|
@everythingfunctional good example. So the issue is with transitive modules? I would keep the above example valid and behaving just like today (i.e. module a
integer :: something
end module
module b
use module a
end module
use, namespace :: b
print *, b%a%something
endCan you see any problem with that? P.S. your example does not actually compile with GFortran: module amod
end module
module b
use amod
end module
program main
use b
integer amod
endIt gives: a.f90:10:12:
10 | integer amod
| 1
Error: Symbol ‘main’ at (1) cannot have a typeSo if this is valid, it is not used by people much, if it doesn't even compile. |
|
That seems potentially workable, if possibly tricky to define in the standard, but I haven't thought about it real hard yet, and you'll have to convince Data subgroup to revisit it. From your example though, wouldn't I'm surprised that example produces an error, and the message doesn't look right. I'm sure you're right that people rarely use the name of a module for something else, but it's still generally better to have backwards compatibility when possible. |
Good point, I meant to write it like this: module a
integer :: something
end module
module b
use, namespace :: a
end module
use, namespace :: b
print *, b%a%something
endBtw, the syntax you used |
Was just typing without thinking hard about syntax and somehow got an extra word. It was unintentional. |
|
You can avoid this confusion by omitting the |
|
I was wondering if any thought has been given to namespaces enabling using libraries in the same project that have the same module names? Currently, I think it's not possible with Fortran? e.g., you have two separate libraries used internally by two separate libraries, but both named |
|
@jacobwilliams I think that's a separate feature: nesting modules like in Python, which allows you to have the same module name at different places in the (directory) tree of modules. |
Not really. And even if we did do something to help with that problem, it certainly wouldn't be in a way that doesn't require you to change the module, at which point just renaming the module isn't really that bad. |
So you can require module data to be referenced like module.var:
One issue with just
use utilsis that it still pollutes your local namespace withsavetxt, so that's the reason foruse, namespace :: utils.Other alternatives for syntax:
use utils, only(or perhapsuse utils, only:). Another alternative isuse namespace utils(suggested by Milan Curcic). Or perhapsuse, namespace :: utils, to by compatible with the existing syntax likeuse, intrinsic :: iso_fortran_env.Initially proposed by Michael Zingale and further discussed at Twitter.
The text was updated successfully, but these errors were encountered: