This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, fortran] Handling of .and. and .or. expressions


On Wed, Jun 27, 2018 at 10:34 PM, Thomas Koenig <tkoenig@netcologne.de>
wrote:

> Am 27.06.2018 um 21:15 schrieb Janne Blomqvist:
>
> If the semantic model is unclear on whether a function with potential
>> side-effects might or might not be evaluated, then IMNSHO the semantic
>> model is shit, and should be fixed or replaced.
>>
>
> I disagree here, strongly. We are talking Fortran, and not C (where
> everything is a function, and often the whole point of calling a
> function is its side effects).
>

If you can't robustly use functions with side-effects, they shouldn't be in
the language in the first place, IMHO. So either there should be some
sensible semantics for them, or they should be removed. Removing them would
probably break the vast majority of existing Fortran code, so I think
tightening up the semantics is the only reasonable solution.


> And we are not going to change Fortran semantics.


No, not we, here. I'm just expressing some wishful thinking that the
Fortran standards committee would improve this aspect of the standard. But
given Nicks statement that this has been tried, and failed, repeatedly in
the past maybe I shouldn't get my hopes up..

And I also oppose
> defining our own subset of Fortran in the hope that people will make
> fewer mistakes.
>

I agree, and I hope my writings in this thread hasn't been interpreted as
support for such a position. For one thing, if ever the Fortran standards
committee decides on fixing the semantics of functions and on an evaluation
strategy for logical expressions, and it's different from what our
hypothetical "GNU Fortran standard" does, we have caused a lot of headache
for our users and ourselves.

I think the best we can do is to generate a warning, and make standard
conforming code run as fast as possible.


-- 
Janne Blomqvist


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]