[J3] [EXTERNAL] [BULK] Re: Consistency in conversion functions

Tue Apr 4 20:27:53 UTC 2023

Jeff,

First, no one has “rejected” this idea in this thread that I have noticed.   Rather, to varying degree some of us have indicated where we would place this in terms of priorities.

We do not have the resources to take on all reasonable features, and thus we balance the benefits and the costs.    Your feature presumably is low benefit, but also low cost.  The low cost means it might make the cut.   But at the same time, if most on the committee do not value the benefit, other small features will “jump ahead” in line.

One argument in favor of this feature, which has been left implicit in this discussion:    A user cannot implement their own INTEGER() function that behaves as INT().   (In case it is not obvious, it is because the return type depends on the _value_ of its KIND argument.)    In this case you can’t even safely use a simple FPP macro for fear of interacting with variable declarations.  (Unless you have some strict capitalization conventions that would let it work.)

A capability that cannot be implemented by a user _at all_ is generally a good argument in favor of a new feature.   But I must emphasize the word “generally”.

  *   Tom

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Tuesday, April 4, 2023 at 4:09 PM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Jeff Hammond <jehammond at nvidia.com>
Subject: [EXTERNAL] [BULK] Re: [J3] Consistency in conversion functions

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

I don’t think it’s healthy for committee members to reject ideas just because they solve problems that don’t bother said members. Most of the proposals I’ve seen solve problems I’ve never even imagined and yet I trust that if they matter to others, they are worthy of my time, or at least not worthy of my negativity in the absence of obvious flaws.

To give a specific example, I’ve literally never wanted generic programming in Fortran and yet I support what Tom is doing because (1) it doesn’t cost me a dime to watch him work and (2) I trust that other people will benefit from it.

On 4. Apr 2023, at 22.25, Brad Richardson via J3 <j3 at mailman.j3-fortran.org> wrote:
External email: Use caution opening links or attachments

I'm sympathetic with the desire for consistency within the language, but this is not a thing that has ever really bothered me. I think there's other issues more worthy of our time.

Brad

On Tue, 2023-04-04 at 07:52 +0000, Jeff Hammond via J3 wrote:
To convert INTEGER kinds, we use INT().
To convert COMPLEX kinds, we use CMPLX().
To convert REAL kinds, we use REAL().
To convert LOGICAL kinds, we use LOGICAL().

Does this bother anyone else?

Are there technical or non-technical reasons why we bring consistency to this situation, by adding INTEGER() and COMPLEX() conversion intrinsics?  I have found the need to use INT() surprising and annoying often enough to have a practical motivation to solve this, not just an aesthetic one.

The only issue I see is that GNU has an extension COMPLEX() but I don’t see an incompatibility with CMPLX there, because the behavior of COMPLEX is a subset of CMPLX.

Thanks,

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20230404/2627a90d/attachment-0001.htm>