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 <notifications@github.com>
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 <notifications@github.com>
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 |
The word name itself as a verb or the word rename. However, I find all of the proposed keywords as non-Fortranic way of doing things. With the only exception perhaps of the original proposal of namespace. use mathematics, only: cdif=>central_difference
call cdif()
!to
use, namespace, math=>mathematics, only:cdif=>central_difference
call math%cdif()The keyword namespace will be employed to distinguish between using or not using the name of the module and the symbol Another alternative to namespace could be modulename, only because the former may cause confusion with the C++ keyword, and why not to reserve it for a possible future similar implementation. use, modulename, math=>mathematics, only:cdif=>central_difference
call math%cdif() |
|
I will request everyone to take a look at my comment in another thread #86, a thread with another proposal that I think is along the same lines as this one. As I suggest therein, I personally would preface NAMESPACE to reflect a formal concept that is waiting to be introduced in the Fortran standard at some later stage in the advancement of this language. Fortran being a language that always holds tremendous promise as a tool for scientists and engineers but which is perpetually trying to "catch up" to the state-of-the-art in technical computing. Meaning the language and its bearers haven't fully caught up yet to the concept of namespace and its benefits though Fortran did a take a big step toward it with MODULEs introduced back in 1991 with the Fortran 90 publication. In the context of this particular proposal in this thread, I think the search is for a way to decorate module entities suitably during their "consumption" via USE association. And I think the Fortrannic way will be to introduce both an ATTRIBUTE and a STATEMENT for the same. And where the options gain a FUNCTION-like syntax with optional arguments within parenthesis. There are several examples of this in the Fortran standard: ALLOCATABLE, BIND, etc. So thinking along the same lines, an alternate suggestion will be to use use, decorate :: utils
..
call utilsXsavetxt(..)where X is the separator yet to be decided; it can be And additional options with (re)naming can be introduced as use, decorate( name="ut" ) :: utils
..
call utXsavetxt(..)With the STATEMENT form, the expected syntax is use utils
..
decorate :: utils
..
call utilsXsavetxt(..)Applying the same to @smeskos 's examples above, I would expect the syntax to be use, decorate(name="math") :: mathematics, only : cdif => central_difference
call mathXcdif()And if the optional use, decorate :: mathematics, only : cdif => central_difference
call mathematicsXcdif()With the example in the J3 paper (https://j3-fortran.org/doc/year/19/19-246.txt), the syntax can look like so: use, decorate :: math
use, decorate( name="np" ) :: numpy
use, decorate( name="sym") :: sympy
...
e1 = npXsin(npXpi) ! NumPy expression
e2 = mathXsin(mathXpi) ! Built-in Python math expression
e3 = symXsin(symXpi) ! SymPy expressionand use, decorate :: lapack
..
call lapackXdgeev('N', 'V', n, At, lda, wr, wi, vl, ldvl, vr, ldvr, &
work, lwork, info)
..
call lapackXdgetrf(n, n, Amt, lda, ipiv, info)
.. |
|
I find "decorate" concept elegant, except I am not sure why the alternative
name is to be put in quotes. In free form, spaces or special characters are
not allowed in names afaik, while string literal implies that any
characters should be valid. I think that
use, decorate(name = lpk) :: lapack
would be more logical.
When I look at this syntax, it really looks like Fortran to me. Good shot
FortranFan.
Also because one USE is needed to include one module, while => operator
usually appears in constructs that can be used in sequences separated by a
comma. So
use, namespace :: np => numpy
naturally encourages user to do
use, namespace :: np => numpy, lpk => lapack
which would be too much of a stretch considering current USE syntax.
I also would agree that using % (so the same operator used to access
derived type components) should be very carefully discussed. I would also
prefer to have a distinguishment between accessing module and derived type
components. :: seems to be another good candidate. While I love Python and
in that language no distinguishment makes sense (its an interpreted
language), I would say in Fortran I would rather know whether it's a
derived type or just a namespace. There is enough confusion as is with
parethesis () used both for functions and arrays. Let's not repeat that
mistake.
Dominik
sob., 26 wrz 2020 o 19:30 FortranFan <notifications@github.com> napisał(a):
… I will request everyone to take a look at my *comment*
<#86 (comment)>in
another thread #86
<#86> that I think
is related to this one. As I suggest therein, I personally would preface
NAMESPACE to reflect a *formal* concept to be introduced in the Fortran
standard at some later stage in the advancement of this language that
always holds tremendous promise as a tool for scientists and engineers but
which is perpetually trying to "catch up" to the state-of-the-art in
technical computing. Meaning the language and its bearers haven't fully
caught up yet to the concept of namespace and its benefits though Fortran
took a big step toward it with MODULEs back in 1991 with Fortran 90
publication.
In the context of this particular proposal in this thread, I think the
search is for a way to *decorate* module entities suitably during their
"consumption" via USE association.
And I think the *Fortrannic way* will be to introduce both an ATTRIBUTE
and a STATEMENT for the same. And where the options gain a FUNCTION-like
syntax with optional arguments within parenthesis.
There are several examples of this in the Fortran standard: ALLOCATABLE,
BIND, etc. BIND seems to me to be quite apt here for understanding a
facility that is both an ATTRIBUTE and a STATEMENT. Note the token BIND
in my simple-minded thinking can be viewed as a verb or a command or an
instruction which is what seems to be the need here.
So thinking along the same lines, an alternate suggestion will be to use
DECORATE as the token:
use, decorate :: utils
..call utilsXsavetxt(..)
where X is the separator yet to be decided; it can be % (as in call
utils%savetxt(..)) or it might be double-colon (as in call
utils::savetxt(..)), etc.
And additional options with (re)naming can be introduced as
use, decorate( name="ut" ) :: utils
..call utXsavetxt(..)
With the STATEMENT form, the expected syntax is
use utils
..
decorate :: utils
..call utilsXsavetxt(..)
Applying the same to @smeskos <https://github.com/smeskos> 's examples
above, I would expect the syntax to be
use, decorate(name="math") :: mathematics, only : cdif => central_differencecall mathXcdif()
And if the optional name is not employed,
use, decorate :: mathematics, only : cdif => central_differencecall mathematicsXcdif()
With the example in the J3 paper (
https://j3-fortran.org/doc/year/19/19-246.txt), the syntax can look like
so:
use, decorate :: math
use, decorate(name="np") :: numpy
use, decorate( name="sym") :: sympy
...
e1 = npXsin(npXpi) ! NumPy expression
e2 = mathXsin(mathXpi) ! Built-in Python math expression
e3 = symXsin(symXpi) ! SymPy expression
and
use, decorate :: lapack
..
call lapackXdgeev('N', 'V', n, At, lda, wr, wi, vl, ldvl, vr, ldvr, &
work, lwork, info)
..
call lapackXdgetrf(n, n, Amt, lda, ipiv, info)
..
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4NA3O3N7FNNZ3GMNFHHO3SHYQMNANCNFSM4JBFRGNA>
.
|
|
I also like @FortranFan's idea of specifying the namespace name in parentheses following the keyword. Also with @gronki that the new name shouldn't be a string literal. I don't like the word "decorate" here. To me it means to add functionality to something which I don't think is what we're doing. |
|
I'm ok with the synonym to be not a string literal i.e., a Re: "I don't like the word "decorate" here. To me it means to add functionality to something which I don't think is what we're doing.":
Then, in the dictionary sense of the term, this is nothing but decoration. That's why I suggested that token. It seems to better capture the essence of the functionality being proposed here than all the alternatives suggested upthread. But if it's too verbose, another alternative is By the way, I had thought of Now, if people starting getting too much into further nits with the choice of the word, that will confirm @wclodius2 's point earlier about the bikeshedding here. |
|
Yeah perharps the choice of a word is a bit of a detail. From my
perspective as a non-native English speaker, the word should be
commonly used in international English (never seen "adorn" before) and
not to be confused with something else (like IMPORT proposed in
another context). I am sure there is one than more word that fits this
criteria :)
Dominik
niedz., 27 wrz 2020 o 19:02 FortranFan <notifications@github.com> napisał(a):
…
@gronki, @milancurcic ,
I'm ok with the synonym to be not a string literal i.e., a default-char-constant-expr per the standard. I had suggested as much based on what I thought I had heard previously with certain compiler implementations and how they parse the FUNCTION-like approach with the use of parenthesis in ATTRIBUTEs and STATEMENTs. This is where an implementation or two, as suggested by @certik, will come in handy: it can help work through such options.
@milancurcic ,
Re: "I don't like the word "decorate" here. To me it means to add functionality to something which I don't think is what we're doing.":
note this proposal is indeed adding a functionality, albeit it is in the form of an adornment or an embellishment. What might previously be a use-associated entity FOO from MY_MOD module will no longer have its first-class (or an independent) identity that it has with current standard. Meaning, there can no longer be a reference to FOO in that scope. It must be "adorned" as something like MY_MOD::FOO (or MY_MOD%FOO, depending on the separator chosen.)
Then, in the dictionary sense of the term, this is nothing but decoration. That's why I suggested that token. It seems to better capture the essence of the functionality being proposed here than all the alternatives suggested upthread.
But if it's too verbose, another alternative is ADORN. But if people starting getting into further nits with the choice of the word, that will confirm @wclodius2 's point earlier about the bikeshedding here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@FortranFan Thank you, only after your detailed explanation I was able to understand--you're not decorating the module itself, but the public entities in the module. Now it makes more sense. I'd still advise against it because of how easily it can be confused with decorating as a software design pattern. For example, if I was teaching this concept, I'd have to caveat it with something like "If you've used decorators in other languages before, be careful--this does something completely different", and then refer to it as "namespace" in the rest of the material. :) This is also a good example of why I think the choice of the word is important. |
|
@septcolor wrote:
As mentioned upthread, punctuation or a separator between conjunctions is needed to support the 2 sources forms in Fortran, and that's why this does not work. |
|
Thanks everybody for your input and making progress on this issue. @septcolor raises an important thing to consider: #86 (nested modules). As posted there, this might work: I like the Don't know if there could be issues parsing it. Another issue to consider is nested modules (proposed feature as in #86) versus modules using other modules (existing feature) with regards to syntax and importing. E.g., does |
|
There seems to have been a consensus that there should be a poll/vote on the preferred syntax. As there has been a significant pause in postings on this issue, I think it is an appropriate to summarize our current syntactic options to prompt more suggestions for options. There are four orthogonal choices in the syntax:
What word to useSo far I have seen the following suggestions for keywords:
Are there any names I missed? With this many options it might be best to do a ranked choice vote. Where to put the keywordI know of three possible places to put the keyword
How to rename modulesI have noted three ways to do module renaming:
What to use as accessor operatorI have noted two suggestions for the accessor operator
In principle other characters could also be used: backtick, FWIW I tend to prefer the shorter keywords, but dislike overloading the meaning of "only" and "import". So my first preference is Edit: Formatting by @milancurcic for readability |
|
Thank you for the summary @wclodius2, it's very helpful. Here's my current preference:
Examples:
Addendum to the syntax proposal which would allow orthogonal imports as @klausler suggested: It's possible to use the Example: This statement would import To prevent writing confusing code, shouldn't be allowed IMO. |
|
I didn't think about that. It does seem like the most elegant solution. Simply make it available as a namespace if you don't need it renamed. It's backward compatible because, as you say, it has been impossible to reference a module name after a |
|
First Fortran module names tend to be long to reduce the possibility of name clashes so most of the time users would find renaming useful though it could be
use[(name=local-module-name)][[,module-nature]::]module-name..;.
Second some users will want the processor to enforce the use of the module name as a qualifier which in turn requires the use of a different syntax to let the processor know that that is a requirement.
|
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 |
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: