Assert

[wclodius2]

A paper on design by contract that, among other things, proposes the addition of an ASSERT statement
to Fortran 202y.

[milancurcic]

Thank you @wclodius2, I read the proposal. Do requires and ensures do anything different from asserts other than being required to be in the prelude and conclusion of a procedure, respectively? Why not use just asserts?

I have a slight preference for imperative mood for statements like this (require instead of requires, assert instead of asserts), which is consistent with other Fortran statements (allocate, deallocate, nullify, open, close, read, write, inquire, change team, form team, etc.)

[nncarlson]

I would find it useful to have an additional statement INSIST that behaves identically to ASSERT except that it is active in both development and deployment compilation modes; i.e., it is never a null operation.

[wclodius2]

The change is good.

…

On Aug 4, 2020, at 3:15 PM, Milan Curcic ***@***.***> wrote: @milancurcic commented on this pull request. In proposals/assert/design_by_contract.txt <#177 (comment)>: > +REQUIRE and ENSURES can be thought of as either sub-program attributes +or executable statements. If treated as sub-program attributes then +the syntax could be something like + + requires-stmt is EEQUIRES :: requires-expr-list + ensures-stmt is ENSURES :: ensures-expr-list + + requires-expr is logical-expr + ensures-expr is logical-expr + +Constraint: requires-expr shall be a restricted expression. + +If thought of as run time expressions then the appropriate syntax may +be + + requires-stmt is EEQUIRES( requires-expr-list ) ⬇️ Suggested change - requires-stmt is EEQUIRES( requires-expr-list ) + requires-stmt is REQUIRES( requires-expr-list ) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#177 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOWNE4FYZCOMOYSYDI3R7B27RANCNFSM4PUZU5SA>.

[wclodius2]

Having them be different from assert calls them out to users of the procedure, and to automatic processing codes such as FORD. They naturally suggest documentation such as ASIN(X) requires X>= -1, and X<=1, and ensures the result is >= -pi/2 and <= pi/2. The requires and ensures are aspects of the public interface of a procedure, and are important to users of the procedure, while assert is important only to the developer of the procedure.

…

On Aug 4, 2020, at 3:33 PM, Milan Curcic ***@***.***> wrote: Thank you @wclodius2 <https://github.com/wclodius2>, I read the proposal. Do requires and ensures do anything different from asserts other than being required to be in the prelude and conclusion of a procedure, respectively? Why not use just asserts? I have a slight preference for imperative mood for statements like this (require instead of requires, assert instead of asserts), which is consistent with other Fortran statements (allocate, deallocate, nullify, open, close, read, write, inquire, change team, form team, etc.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#177 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOTMKJL7B4JCHRSLATDR7B5B7ANCNFSM4PUZU5SA>.

[wclodius2]

FWIW I slightly prefer the active voice.

[wclodius2]

I don't seem to have write access to the repository, so I have to ask others to make changes for my approval. As it is always an executable construct ASSERT should always be in the active voice. Can someone change all appearances of ASSERTS to ASSERT? When discussed as an attribute statement I believe I should use REQUIRES and ENSURES, while when discussed as an executable statement I believe I should use REQUIRE and ENSURE. Can someone make that selected change?

[nncarlson]

@wclodius2 I'm not sure what errors you're seeing, but you should be able to make changes to your pull request. Looks like Milan committed a couple changes to it. So perhaps you need to do a git pull on your assert branch to pull those changes into your working copy before you can commit your changes and push them back to the assert branch on your fork of the repo.

[wclodius2]

It has been a month and none of my three proposals (assertions/design by contract; optional dummy arguments, and module namespaces) have been merged into the repository. Did they "fall off the radar"? Did they need more work? Are they inappropriate for meeting 222, as they are explicitly F202y oriented and so low priority? Are there other reasons I am not thinking of?

[certik]

@wclodius2 in the past we usually merged the pull requests before the meeting once we were happy with the wording and it was the version we wanted to present. I am happy to merge it sooner if you would prefer.

In the last meeting we presented such proposals at the plenary to get feedback from the whole committee. These proposals go into 202y, so the committee does not vote on them. The idea is to get them ready, so that when the committee starts considering proposals for 202y, they are ready.

In order to increase chances of the proposal getting accepted, it's good to involve as much of the wider community as possible. If there is wide support for some feature, it has a much higher chance of getting in.

[wclodius2]

In the past the nominal due date for proposals was two weeks before the meeting, with most proposals arriving a few days before the schedule. This means most proposals were read in a rush in the two week period before the meeting. I think where possible F202X proposals should be submitted a month in advance so there is a likelihood of feedback before the meeting. As these are F202Y proposals they don’t need as prompt a feedback, but still I think they should get in before the two week deadline so there is a possibility of pre meeting commentary.

…

On Sep 13, 2020, at 8:57 PM, Ondřej Čertík ***@***.***> wrote: @wclodius2 <https://github.com/wclodius2> in the past we usually merged the pull requests before the meeting once we were happy with the wording and it was the version we wanted to present. I am happy to merge it sooner if you would prefer. In the last meeting we presented such proposals at the plenary to get feedback from the whole committee. These proposals go into 202y, so the committee does not vote on them. The idea is to get them ready, so that when the committee starts considering proposals for 202y, they are ready. In order to increase chances of the proposal getting accepted, it's good to involve as much of the wider community as possible. If there is wide support for some feature, it has a much higher chance of getting in. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#177 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOVH3FDE7H7KTV5IOMTSFWBBVANCNFSM4PUZU5SA>.

[certik]

Ok, let's merge it.