-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revised version of the default arguments proposal #175
base: master
Are you sure you want to change the base?
Conversation
Thanks for submitting this!
I like this. The only thing I am not sure is to specify the default expression in the subroutine statement. Indeed that is how other languages do that, but those languages also define the type there. In Fortran we define types separately from the subroutine line. So I think the default value should be initialized at the declaration also.
Note also that in your proposal the default keyword is redundant. If you remove it, you arrive at the initial proposal from Milan. See the discussion at the original issue.
…On Sat, Jul 11, 2020, at 10:31 PM, William B. Clodius wrote:
I have written a revision of the paper by @milancurcic
<https://github.com/milancurcic>, @jvdp1 <https://github.com/jvdp1>,
and @zjibben <https://github.com/zjibben> that attempts to address most
of the issues raised at the Feb. 25 meeting, and a few other issues
that have come to my mind. The paper differs from the original
primarily by:
Restricting optional arguments to arguments with the INTENT(IN), VALUE,
or no intent attributes.
Requiring arguments with a default assignment to be explicitly given
the DEFAULT attribute.
Forbidding arguments from having both the DEFAULT and OPTIONAL
attributes so that the PRESENT function retains its semantics.
Allowing the expression on the right of the default assignment be a
restricted expression and not just a constant expression.
Strongly encouraging that the default assignment be in the FUNCTION or
SUBROUTINE statement (and not the TYPE declaration statement) as
probably being easier to parse.
Discussing the implications of the constraints on intrinsic assignment,
10.2.1.2, their interpretation, 10.2.1.3, and the constraints on
defined assignment, 10.2.1.4, and their interpretation, 10.2.1.5 on
default array assignments.
Briefly discussing the implications of an argument with the DEFAULT
attribute also having any one of the POINTER, VOLATILE, ASYNCHRONOUS,
or TARGET attributes.
You can view, comment on, or merge this pull request online at:
#175
Commit Summary
* Revised version of the default arguments proposal
File Changes
* *A* proposals/default_optional_arguments/revised_proposal.txt
<https://github.com/j3-fortran/fortran_proposals/pull/175/files#diff-0f4b23a04e6db2e930f7b3c74a4ee745> (356)
Patch Links:
* https://github.com/j3-fortran/fortran_proposals/pull/175.patch
* https://github.com/j3-fortran/fortran_proposals/pull/175.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#175>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAFAWB4FNJQ3V2VYWYLKOTR3E4BNANCNFSM4OXT2LXA>.
|
OTOH I suspect that overriding the default assignment will normally be done by “assignment" to the named argument in the procedure call. The similarity to the usage I find attractive. I also find it very awkward attempting to distinguish between the constant assignment that gives the save attribute to local variables, and the proposed default assignment to arguments. The definition of an entity declaration in the TYPE declaration statement will become even more complex.
The DEFAULT keyword is redundant in the same sense that the OPTIONAL keyword is redundant. Fortran could have implicitly assigned the default attribute to any argument that is used with the PRESENT() function. I find the DEFAULT keyword very useful in distinguishing between arguments with the DEFAULT and OPTIONAL attributes. Redundancy isn’t always bad. See what happened to the SAVE attribute.
… On Jul 11, 2020, at 10:59 PM, Ondřej Čertík ***@***.***> wrote:
Thanks for submitting this!
I like this. The only thing I am not sure is to specify the default expression in the subroutine statement. Indeed that is how other languages do that, but those languages also define the type there. In Fortran we define types separately from the subroutine line. So I think the default value should be initialized at the declaration also.
Note also that in your proposal the default keyword is redundant. If you remove it, you arrive at the initial proposal from Milan. See the discussion at the original issue.
On Sat, Jul 11, 2020, at 10:31 PM, William B. Clodius wrote:
> I have written a revision of the paper by @milancurcic
> <https://github.com/milancurcic>, @jvdp1 <https://github.com/jvdp1>,
> and @zjibben <https://github.com/zjibben> that attempts to address most
> of the issues raised at the Feb. 25 meeting, and a few other issues
> that have come to my mind. The paper differs from the original
> primarily by:
>
> Restricting optional arguments to arguments with the INTENT(IN), VALUE,
> or no intent attributes.
>
> Requiring arguments with a default assignment to be explicitly given
> the DEFAULT attribute.
>
> Forbidding arguments from having both the DEFAULT and OPTIONAL
> attributes so that the PRESENT function retains its semantics.
>
> Allowing the expression on the right of the default assignment be a
> restricted expression and not just a constant expression.
>
> Strongly encouraging that the default assignment be in the FUNCTION or
> SUBROUTINE statement (and not the TYPE declaration statement) as
> probably being easier to parse.
>
> Discussing the implications of the constraints on intrinsic assignment,
> 10.2.1.2, their interpretation, 10.2.1.3, and the constraints on
> defined assignment, 10.2.1.4, and their interpretation, 10.2.1.5 on
> default array assignments.
>
> Briefly discussing the implications of an argument with the DEFAULT
> attribute also having any one of the POINTER, VOLATILE, ASYNCHRONOUS,
> or TARGET attributes.
>
> You can view, comment on, or merge this pull request online at:
>
> #175
>
> Commit Summary
>
> * Revised version of the default arguments proposal
> File Changes
>
> * *A* proposals/default_optional_arguments/revised_proposal.txt
> <https://github.com/j3-fortran/fortran_proposals/pull/175/files#diff-0f4b23a04e6db2e930f7b3c74a4ee745> (356)
> Patch Links:
>
> * https://github.com/j3-fortran/fortran_proposals/pull/175.patch
> * https://github.com/j3-fortran/fortran_proposals/pull/175.diff
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#175>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAFAWB4FNJQ3V2VYWYLKOTR3E4BNANCNFSM4OXT2LXA>.
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#175 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOXGU3FXEWTOBNP6WS3R3E7JZANCNFSM4OXT2LXA>.
|
After checking my Ada textbook, I found that one thing I wrote about Ada is wrong so I am going to correct the proposal. |
Removed the comment implying Ada was the exception in having a specification part. |
This would invalidate existing code, yes? |
@klausler I'm pretty sure @wclodius2 meant "Restricting default arguments...". This proposal won't invalidate existing code. If it does, we will fix it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this revision.
I added minor comments around "no intent" and intent(inout)
. I am not sure what the issues are.
Fortran 2018 does not allow setting a default value for optional | ||
arguments. A default value is the value that the dummy argument | ||
would take if the corresponding actual argument is not present. If a | ||
dummy argument of INTENT(IN) or VALUE, or no intent is declared as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is no intent
equivalent to intent(inout)
?
This proposal addresses the issue for INTENT(IN), VALUE, and no intent | ||
arguments that checking for the presence of the optional dummy | ||
argument and using a helper variable is cumbersome and error-prone. We | ||
will not address default values for INTENT(OUT) OR INTENT(INOUT) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure to understand why intent(inout)
is not considered.If no argument is passed, then intent(inout)
would behave as intent(in)
?
languages C++ and Ada may be the best known with default arguments. Of | ||
these languages, Ada may be the most pertinent as it has INTENT | ||
arguments similar to Fortran's. Ada has only defined default arguments | ||
useful for INTENT(IN), and has not defined it for INTENT(OUT) or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know Ada. What does it implement for "no intent"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ada doesn't have that option. For its parameters (the Fortran arguments) you always have to specify INTENT with either IN, OUT, or INOUT.
After having read the document, you should indeed read "Restricting default arguments...". |
A thinko. The proposal talks about restricting **default** arguments to arguments with the INTENT(IN), VALUE, or no intent attributes, which doesn’t invalidate existing code.
… On Jul 12, 2020, at 12:04 PM, Peter Klausler ***@***.***> wrote:
Restricting optional arguments to arguments with the INTENT(IN), VALUE, or no intent attributes.
This would invalidate existing code, yes?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#175 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOX2O63XOWBLYBUV523R3H3JZANCNFSM4OXT2LXA>.
|
Unfortunately no intent is not equivalent to intent(inout), though I wouldn’t object strongly if the revised proposal dropped allowing default assignment for no intent. INTENT(INOUT) means that the input value is always intended to be used and an output value is always expected. No INTENT could behave as an INTENT(IN), INTENT(OUT), or INTENT(INOUT), and its behavior could depend dynamically on the other arguments.
… On Jul 12, 2020, at 12:40 PM, Jeremie Vandenplas ***@***.***> wrote:
@jvdp1 commented on this pull request.
Thank you for this revision.
I added minor comments around "no intent" and intent(inout). I am not sure what the issues are.
In proposals/default_optional_arguments/revised_proposal.txt <#175 (comment)>:
> +
+1. Introduction
+
+This paper contains a proposal for Fortran 202y, to allow a programmer
+to specify a default value for a subset of optional dummy
+arguments. This would allow the programmer to then safely reference
+such arguments in expressions regardless of whether the actual
+argument is present or not.
+
+
+2. Problem
+
+Fortran 2018 does not allow setting a default value for optional
+arguments. A default value is the value that the dummy argument
+would take if the corresponding actual argument is not present. If a
+dummy argument of INTENT(IN) or VALUE, or no intent is declared as
Is no intent equivalent to intent(inout)?
In proposals/default_optional_arguments/revised_proposal.txt <#175 (comment)>:
> +
+This differs from the INTENT(IN), VALUE, and no intent case: first,
+because one assigns the default value with INTENT(OUT) when the actual
+argument is present, not when it is absent; and second, because the
+assignment of a default involves only one statement rather than the
+three statements for the helper variable of INTENT(IN), VALUE, and no
+intent. For INTENT(INOUT), one typically makes the argument optional
+to avoid the computational expense of calculating the out result, but
+having a default value makes it awkward to determine the presence of
+an optional argument, so the primary purpose of having it be optional
+is defeated.
+
+This proposal addresses the issue for INTENT(IN), VALUE, and no intent
+arguments that checking for the presence of the optional dummy
+argument and using a helper variable is cumbersome and error-prone. We
+will not address default values for INTENT(OUT) OR INTENT(INOUT)
I am not sure to understand why intent(inout) is not considered.If no argument is passed, then intent(inout) would behave as intent(in)?
In proposals/default_optional_arguments/revised_proposal.txt <#175 (comment)>:
> +greatest in scenarios where the optional argument is used in many
+places in the procedure, and a helper variable is used for its value
+instead. Reduction in needed source code would result in more readable
+and more correct programs.
+
+
+3. Prior art
+
+We are not aware of any Fortran compiler that has implemented default
+arguments. However it is a very common feature of other languages. Of
+interpreted languages widely used in the scientific community:
+Python, IDL, R, and Matlab all have default arguments. Of compiled
+languages C++ and Ada may be the best known with default arguments. Of
+these languages, Ada may be the most pertinent as it has INTENT
+arguments similar to Fortran's. Ada has only defined default arguments
+useful for INTENT(IN), and has not defined it for INTENT(OUT) or
I don't know Ada. What does it implement for "no intent"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#175 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOVNQNPJVPHR7QL5F5DR3H7SVANCNFSM4OXT2LXA>.
|
Thank you for the precisions. Therefore, because "no intent" could behave as an |
Like I said I have no strong feelings about no intent. The users can do a lot of things in almost any programming language that I would consider foolish. With no intent the user could also write the code in such a way that when he provides no argument so the default is used, the routine behaves like an INTENT(IN) and behaves like INTENT(INOUT) otherwise.. Whatever we decide we should discuss the implications for no intent, either requiring that an argument with the DEFAULT may not have the INTENT(INOUT) or INTENT(OUT) (implicitly allowing no intent), or require that arguments with the DEFAULT attribute must have one of the attributes INTENT(IN) or VALUE (implicitly disallowing no intent).
… On Jul 12, 2020, at 2:07 PM, Jeremie Vandenplas ***@***.***> wrote:
Unfortunately no intent is not equivalent to intent(inout), though I wouldn’t object strongly if the revised proposal dropped allowing default assignment for no intent. INTENT(INOUT) means that the input value is always intended to be used and an output value is always expected. No INTENT could behave as an INTENT(IN), INTENT(OUT), or INTENT(INOUT), and its behavior could depend dynamically on the other arguments.
Thank you for the precisions. Therefore, because "no intent" could behabe as an intent(out), wouldn't it make sense to not allowing default assignment for "no intent"? Otherwise, users could just drop "intent(out)" and add a default value for an argument actually behaving as intent(out)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#175 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDORHEY47PL72S6NERJLR3IJWTANCNFSM4OXT2LXA>.
|
Minor improvements in wording over 20-108.txt. More use cases. Changed NAMESPACE attributes to WITH attribute.
Instead of assuming that arguments with no intent are treated the same as arguments with the INTENT(IN) or VALUE attributes, I discuss no intent arguments separately and leave it up to others to decide how to treat no intent arguments.
I don't like specifying the default value in the argument list as in One objection from the committee I believe is that the syntax |
I don't understand this objection because dummy arguments can't have a save attribute. I am also okay with not mixing |
You need to decide whether the default value of a dummy argument (or just that fact that it has one) is meant to be a characteristic of the procedure or not. This matters in the implementation, because it determines whether an implementation has the freedom to implement the default value in the caller (as in C++) or in the called subprogram, or whether the language is forcing one or the other. Why this matters: if the default value of a dummy argument is an expression involving other dummy arguments, host-associated variables, module or COMMON objects, &c., implementing the evaluation of the default value in the caller can be difficult or impossible. But if default values are expressions to be evaluated if need be in the called subprogram, then the value need not be part of the characteristics or interface, and the implementation of the calling side is no different from an |
Peter, when I discussed that at the last meeting (after the plenary), I think our idea was to implement the default value in the caller, which enables the compiler to compile the subroutine ahead of time without any if statements, and call it exactly the same way no matter if the user provides the default argument or not. You have a good point about what if the default value is an expression involving other dummy arguments that it might be impossible. I don't know yet if it is impossible, and so a prior compiler implementation would be in order here. At least in gfortran it seems any of these expressions (such as a length of an array) is part of the function signature, so this would be also. |
Seems like a compelling use case to me, but the default has to be implemented in the called subprogram to make it work. So there's reasons why defaults should be implemented in callees, and the only argument for implementing them in callers (it might save a predictable branch) is weak and also has other obvious solutions. |
I see. The nested subroutine |
Here's an idea: extend the |
I have written a revision of the paper by @milancurcic, @jvdp1, and @zjibben that attempts to address most of the issues raised at the Feb. 25 meeting, and a few other issues that have come to my mind. The paper differs from the original primarily by:
Restricting optional arguments to arguments with the INTENT(IN), VALUE, or no intent attributes.
Requiring arguments with a default assignment to be explicitly given the DEFAULT attribute.
Forbidding arguments from having both the DEFAULT and OPTIONAL attributes so that the PRESENT function retains its semantics.
Allowing the expression on the right of the default assignment be a restricted expression and not just a constant expression.
Strongly encouraging that the default assignment be in the FUNCTION or SUBROUTINE statement (and not the TYPE declaration statement) as probably being easier to parse.
Discussing the implications of the constraints on intrinsic assignment, 10.2.1.2, their interpretation, 10.2.1.3, and the constraints on defined assignment, 10.2.1.4, and their interpretation, 10.2.1.5 on default array assignments.
Briefly discussing the implications of an argument with the DEFAULT attribute also having any one of the POINTER, VOLATILE, ASYNCHRONOUS, or TARGET attributes.