j3-fortran / fortran_proposals

Proposals for the Fortran Standard Committee
178 stars 15 forks source link

Add namespace modules proposal revision by @wclodius2 #176

Open milancurcic opened 4 years ago

milancurcic commented 4 years ago

Uploaded for @wclodius2. Related to issue #1.

wclodius2 commented 4 years ago

FWIW I don’t have a significant problem with disallowing it, but it requires more changes in the standard than simply allowing it,. In allowing the syntax you want to disallow you need only

  1. Add the new keyword, with;
  2. Add the module rename list; and
  3. Disallow the module rename list if with is omitted;

To disallow the syntax you want to disallow you need to add, probably as constraints:

  1. Disallow the only keyword if with is present; and
  2. Disallow the entity rename list if with is present.

It become a different negotiation i instead of use, with :: … you add a new with::... statement. With a with statement you need:

  1. Add the new keyword with
  2. Add the with statement to the syntax
  3. Have the module rename list in the statement

You are in effect adding a simpler statement rather than complicating an existing statement

On Jul 31, 2020, at 12:22 PM, Ondřej Čertík notifications@github.com wrote:

@certik commented on this pull request.

In proposals/namespace_modules/20-xxx.txt https://github.com/j3-fortran/fortran_proposals/pull/176#discussion_r463762993:

  • use, with :: math, only: vector
  • use, with:: strings, only: vector I believe this should be just:

⬇️ Suggested change

  • use, with :: math, only: vector
  • use, with:: strings, only: vector
  • use, with :: math
  • use, with :: strings the code below would still run. I don't think we should allow user, with :: math, only: vector, what would it do? Allow math%vector, but not math%matrix? Python doesn't allow that, I wouldn't allow that either here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/pull/176#pullrequestreview-459373451, or unsubscribe https://github.com/notifications/unsubscribe-auth/APTQDOT43Y24H66BCKFWUYDR6MDWRANCNFSM4PC33DJQ.

certik commented 4 years ago

I personally do not like allowing use, with :: math, only: vector. Also, if it is allowed, I think the proposal needs to explain more clearly what it would do. I personally would not allow it.

But I am happy to merge it if you just want to keep the proposal as is and discuss at the committee.

wclodius2 commented 4 years ago

Then put it on the back burner. There is no rush for F202y. My attitude is that if there is a lot of activity on an F202Y issue on the GitHub forum, then it probably is not ready for J3. If there is not a lot of activity then we need to ask why. If that is because everyone is happy with the proposal then get it to J3 as soon as possible so non-participants in Git Hub can comment and some work can be done between meetings, even if it is not F202X work. If it is because people are tired of the issue or busy with other things then it may not be ready. As you are both the originator of the first namespace proposals, and the organizer of the Git Hub activities you have a big say as to whether it is ready.

For an F202X issue if there is a lot of activity on the GitHub forum then I would put off submitting it to J3 until about two weeks before the meeting. It means that progress is being made at the local level, and you want to make as much progress as possible before involving all of J3, but you cannot put off involving J3 until after the meeting. The face to face involvement at meetings can resolve issues faster than email exchanges.

On Sep 13, 2020, at 9:24 PM, Ondřej Čertík notifications@github.com wrote:

I personally do not like allowing use, with :: math, only: vector. Also, if it is allowed, I think the proposal needs to explain more clearly what it would do. I personally would not allow it.

But I am happy to merge it if you just want to keep the proposal as is and discuss at the committee.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/pull/176#issuecomment-691789154, or unsubscribe https://github.com/notifications/unsubscribe-auth/APTQDOQDP7HTYGT6T53TIQ3SFWEH7ANCNFSM4PC33DJQ.

septcolor commented 4 years ago

A very peripheral question, but for the J3 meeting, is it usual that participants are given only two weeks for reading proposals and making opinions about it? I am afraid that it is not a sufficiently long time to prepare opinions... (CC: @sblionel) .

sblionel commented 4 years ago

@septcolor The two-week limit is for new papers, though given that J3 meetings often generate dozens of new papers on the fly, it's not clear to me that this matters. Typically papers trickle in over the time between meetings so that two weeks in advance there are 20-30 papers to review (some of which have been there for months.)

We're at an odd stage in the development in that there are only seven work items for which work remains to be done. These all have topics in the j3-fortran.org discussion board (for J3 members only). So far, only a couple of minor papers have been submitted, none about the work items. I have been encouraging members to draft papers, but many are finding it difficult to devote time to this. If this in relation to 202Y proposals (as @wclodius2 suggests), then I suggest doing all discussion here as, at least for the October meeting, which is abbreviated, we may not have a chance to discuss future ideas.

wclodius2 commented 4 years ago

@sblionel so standards development is at an odd state. Enough work has been done on the current draft that there would normally be enough time available to start preliminary work identifying features for the following draft, but because people are having trouble adjusting to COVID-19 telecommuting it is not clear how much progress will be made on the current draft. As a result it is unlikely that any work will be done this session on F202Y, with the possible exception of generics/templates. Understandable, but disappointing.

certik commented 4 years ago

I've been thinking about this.

I don't know if I like with more than namespace. For sure with is easier to type. @wclodius2 can you motivate how with describes that it imports the module as a namespace?

certik commented 4 years ago

My other objection is that I don't understand what use, with :: math, only: vector means. As I suggested, I would not allow it. (I understand your argument about the simplest possible change, but I feel that's secondary.)

wclodius2 commented 4 years ago

There are several possible syntaxes for a namespace requiring statement. I will use with for the examples, as it is shorter, but replace it with namespace if you like.

what we have been using for our examples is

use, with :: module-name

but that interacts oddly with module-nature

use, with, intrinsic:: iso_fortran_env use, intrinsic, with :: iso_fortran_env

and you have to explicitly forbid rename-list and only-list

You could also put the with after the module-name use [, module-nature :: ] module-name, with

where with in effect replaces only making a third kind of use-stmt. This is easier to describe than the form we have been using for our examples.

Finally you could have a namespace statement

with [, module-nature ::] module-name

It is what Ada uses, it is more succinct. It is also easier to describe than the form we have been using for our examples.

On Sep 21, 2020, at 8:10 PM, Ondřej Čertík notifications@github.com wrote:

My other objection is that I don't understand what use, with :: math, only: vector means. As I suggested, I would not allow it. (I understand your argument about the simplest possible change, but I feel that's secondary.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/pull/176#issuecomment-696473481, or unsubscribe https://github.com/notifications/unsubscribe-auth/APTQDOWKSMSFW4TSRK6KEXTSHABRHANCNFSM4PC33DJQ.

wclodius2 commented 4 years ago

Using a module as a namespace you use the module entities always with the module-name.

On Sep 21, 2020, at 8:08 PM, Ondřej Čertík notifications@github.com wrote:

I've been thinking about this.

I don't know if I like with more than namespace. For sure with is easier to type. @wclodius2 https://github.com/wclodius2 can you motivate how with describes that it imports the module as a namespace?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/pull/176#issuecomment-696473139, or unsubscribe https://github.com/notifications/unsubscribe-auth/APTQDOQ6KGIHQGLKNJOHMTLSHABLPANCNFSM4PC33DJQ.

certik commented 4 years ago

Using a module as a namespace you use the module entities always with the module-name.

Yes. I am just trying to understand how the term with describes this. You didn't use with in the above sentence, but you used the term namespace. Update: you did use with in with the module-name. Is that the idea? That with means that you always have to use the entities with the module-name in front?

(I know this is just a term, but for this proposal, the "marketing" is very important, and I want to have a well rounded, well motivated proposal that will work and be intuitive to people.)

P.S. Ada describes their use and with here: https://en.wikibooks.org/wiki/Ada_Programming/Packages#Using_packages

wclodius2 commented 4 years ago

I am having trouble understanding your point. I did use with in the sentence. I could have just as easily left namespace out.

Using a module with the with attribute requires that a module entity always be named with the module-name prepended.

On Sep 21, 2020, at 8:40 PM, Ondřej Čertík notifications@github.com wrote:

Using a module as a namespace you use the module entities always with the module-name.

Yes. I am just trying to understand how the term with describes this. You didn't use with in the above sentence, but you used the term namespace.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/pull/176#issuecomment-696479777, or unsubscribe https://github.com/notifications/unsubscribe-auth/APTQDOUWDGNDMY7JSJX2T53SHAFBVANCNFSM4PC33DJQ.

certik commented 4 years ago

My apologies, I amended my comment at https://github.com/j3-fortran/fortran_proposals/pull/176#issuecomment-696479777, yes you did use with.

Will you be able to join our Fortran call this Friday: https://fortran-lang.discourse.group/t/fortran-monthly-call-september-2020/298/8

Let's discuss this there.

Let me try to reformulate my question: I believe that language "keywords" should be natural and intuitive to describe what the feature is doing. So I want to have a motivation. Here is my best effort to motivate the two options:

But I also have another alternative motivation:

Which of these (if any) make sense to you?

wclodius2 commented 4 years ago

I will try to attend the the Fortran call on Friday. I currently have no conflicts with that time, but that of course can change.

use, with :: math The with keyword comes from: The use of the module entities is always with the module-name.

On Sep 21, 2020, at 8:54 PM, Ondřej Čertík notifications@github.com wrote:

My apologies, I amended my comment at #176 (comment) https://github.com/j3-fortran/fortran_proposals/pull/176#issuecomment-696479777, yes you did use with.

Will you be able to join our Fortran call this Friday: https://fortran-lang.discourse.group/t/fortran-monthly-call-september-2020/298/8 https://fortran-lang.discourse.group/t/fortran-monthly-call-september-2020/298/8 Let's discuss this there.

Let me try to reformulate my question: I believe that language "keywords" should be natural and intuitive to describe what the feature is doing. So I want to have a motivation. Here is my best effort to motivate the two options:

use, namespace :: math The namespace keyword comes from: The math module will be imported as a namespace. use, with :: math The with keyword comes from: The math module will be imported as a namespace where you use the module entities always with the module-name. But I also have another alternative motivation:

use, with :: math The with keyword comes from: The code that contains this line will be used with the math module. Which of these (if any) make sense to you?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/pull/176#issuecomment-696482458, or unsubscribe https://github.com/notifications/unsubscribe-auth/APTQDORM5T2XO5VBF2JTHODSHAGUZANCNFSM4PC33DJQ.

Leonard-Reuter commented 2 years ago

What is the current state of this proposal? I think it is a desperately needed feature. Regarding the discussion over here: I'd also prefer namespace over with. Anybody new to the language will easily understand what the former does, while it requires some guess work for the latter.

sblionel commented 2 years ago

It's on the list for consideration for Fortran 202Y. The Data subgroup's initial comments are:

  1. Namespace for modules The proposals here are multitudinous; much of the functionality is already provided by existing syntax, the main thing that looks useful would be a syntax for "remote access" to module entities, e.g. "modulename % entityname". Not sure % is the best thing for this. Medium desirability, Limited scope, Fairly easy.