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

[Damian Rouson]

The first sentence of Annex B.3.12 in the Fortran 2018 standard states, "The
 specific names of the intrinsic functions are often obscure and hinder
portability."  Thus, there is a precedent for citing the obscurity of an
intrinsic function name as a reason for deprecating the name (which is the
primary effect of deletion, given that most compilers will continue to
support the deleted function).   INT() and CMPLX() are doubly obscure: once
because they can be hard to remember (I even had to scroll back in this
thread to double-check the spelling of CMPLX() before writing it again) and
then again because the names have deep historical motivations that future
committee members are unlikely to remember. I'd classify that as baggage. I
would support a proposal to add INTEGER() and COMPLEX() with equivalent
meanings to INT() and CMPLX(), respectively.

Damian

On Tue, Apr 4, 2023 at 2:16 PM Brad Richardson via J3 <
j3 at mailman.j3-fortran.org> wrote:

> I second what Tom said. I'm not rejecting the idea. Like I said, I'm
> sympathetic. I'm just giving MY opinion about how _I_ would prioritize it.
> If you're inclined to put in the work and propose it, I'm likely enough to
> vote in favor. I'll just note that this conversation alone has taken up
> more time than remembering (or not) whether it's spelled INTEGER or INT has
> ever cost me. If you say it's obnoxious to you, I believe you.
>
> Brad
>
> On Tue, 2023-04-04 at 20:27 +0000, Clune, Thomas L. \(GSFC-6101\) via J3
> wrote:
>
> 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/1e206eb6/attachment.htm>