The MERGE Headache

The MERGE Headache

This function gives me a headache because of its non-lazy evaluation of arguments.  For example, MERGE (A(i), 0, i .GE. 1) aborts when array A's lower bound is 1 and i < 1.  Similarly, MERGE (B, 0, PRESENT(B)) aborts when B is an omitted parameter.  This behavior forces one to write ugly IF/ELSE/ENDIF constructs that make code more difficult to read and comprehend.  I suggest  adding to the language a lazy-evaluation function like IIF, which would enable one to write the above examples as IIF (I .GE. 1, A(I), 0) and IIF (PRESENT(B), B, 0) without fear of aborting.

By the word "ugly", I meant to convey the idea that the forced construct occupies more real estate than its importance justifies.

"Lazy evaluation" is also called "short-circuit evaluation".

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

It's been suggested many times, but there's not enough support on the committee for such a thing. It might get considered again for the next standard after the one currently in development (whose features are frozen.)

Retired 12/31/2016

Since many others have suggested it, the suggestion must have considerable support outside the committee.  I would like to understand the objections.  For example, neither short-circuit nor lazy evaluation seems to exist elsewhere in the current standard (which I have only skimmed).  If this is true, it would be interesting to discuss implementation difficulties that might lie behind the objections.

Fortran has two advantages over the many other languages I have used over a long career: (1) outstanding capabilities for a compiler to optimize the machine code and (2) very good compatibility across different compilers and machines.  I would not want to lose either one.

Well, perhaps taking an extreme point of view, but short circuit evaluation is a potential optimization pessimism - at the moment the order of evaluation of arguments to any procedure (intrinsic or not) or operation is unspecified (or is specified in a way that allows for any order).  That means that a particularly clever compiler could evaluate the arguments in parallel.

Allowing short circuit or specified order evaluation for particular intrinsic procedures and operations would give them a particularly uncomfortable fit with the rest of the language, given the syntax looks the same.  Consequently you'd probably want quite different syntax involved.

In both your example cases, I'd be writing an internal procedure to provide the relevant specified sequence of operations.  I think this results in clearer code anyway, within only a "one-off" requirement of a extra couple of lines of code per use style.


Personnaly, and even if it's not the real subject of the post, I can't understand the use of such instruction (MERGE(A(i),0, i >=0)) simply in order to initialize some of the elements of an array to zero. For me this is a nonsense to use such a complex expression that makes the code less readable for people that are not used to modern fortran standards. It is the same with the use of the icopy and dcopy functions from the blas library used to simply initialize arrays to zero.

Best regards,

What's that thing about beauty and the eyes of the beholder?  The same applies to "ugly".  I'd find the suggested changes in OP to be ugly.  Such things are best handled by one's own procedures if one is keen on them and not made part of the standard.

Leave a Comment

Please sign in to add a comment. Not a member? Join today