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

Steidel, Jon L jon.l.steidel at intel.com
Tue Apr 4 16:34:39 UTC 2023


INTEGER (4) is ambiguous without some context, but Fortran compilers have learned to deal with such things.

-jon

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Jeff Hammond via J3
Sent: Tuesday, April 4, 2023 12:18 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Jeff Hammond <jehammond at nvidia.com>
Subject: Re: [J3] [EXTERNAL] [BULK] Re: Consistency in conversion functions

Consistency is exactly why I want this, and I'm glad that non-human code composition tools motivate it as well.

I see this as essentially trivial to fix.  We just say that INTEGER() does the same thing as INT().  Same for COMPLEX() and CMPLX().  Then we never have to look at them again.

If there are reasons why INTEGER() is hard on a parser, then I would expect us to observe that with REAL() already.  Perhaps the implementers can comment on this.

Jeff

From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> on behalf of Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Date: Tuesday, 4. April 2023 at 19.14
To: General J3 interest list <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov<mailto:thomas.l.clune at nasa.gov>>
Subject: Re: [J3] [EXTERNAL] [BULK] Re: Consistency in conversion functions
External email: Use caution opening links or attachments

Hi Steve,

The challenge is when one is writing macros do some of these things generically.    Not the end of the world, but one ends up needing to pass additional arguments to distinguish between the type and the converter.  Annoying but not catastrophic.

I would not be opposed to the additional intrinsics suggested here, but I'm sure it would be rather far down my list of priorities.


-          Tom

From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> on behalf of j3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Reply-To: j3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Date: Tuesday, April 4, 2023 at 11:18 AM
To: j3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Steve Lionel <steve at stevelionel.com<mailto:steve at stevelionel.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.




On 4/4/2023 3:52 AM, Jeff Hammond via J3 wrote:
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.

Technical reason - FORTRAN 66 limited function names to six characters.
Yes, we could now create aliases for these with longer names as
"syntactic sugar", but it would not add functionality.

A COMPLEX intrinsic has been proposed before, with slightly different
semantics from CMPLX - see
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fj3-fortran.org%2Fdoc%2Fyear%2F08%2F08-293r1.txt&data=05%7C01%7Cthomas.l.clune%40nasa.gov%7C87012452196a401afb3708db351fdfb9%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638162183244464697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GwqAeeunSiNDalxsGLAIGEJFhForALPEvt9CMA%2BotRw%3D&reserved=0  WG5<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fj3-fortran.org%2Fdoc%2Fyear%2F08%2F08-293r1.txt&data=05%7C01%7Cjehammond%40nvidia.com%7C4a535eb0ec9d49938de408db35279940%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638162216412834944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XbRi%2BkTbxXhYcP6LJpNGDaVGGp8K8mUA5Zs8Pu1BFdA%3D&reserved=0> voted to not add it
to the worklist (https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fj3-fortran.org%2Fdoc%2Fyear%2F09%2F09-100.txt&data=05%7C01%7Cthomas.l.clune%40nasa.gov%7C87012452196a401afb3708db351fdfb9%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638162183244464697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RveMYpo8bQO%2BBiujwqpd5qS%2Bg5IEdabN%2Fv6nztNvl6c%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fj3-fortran.org%2Fdoc%2Fyear%2F09%2F09-100.txt&data=05%7C01%7Cjehammond%40nvidia.com%7C4a535eb0ec9d49938de408db35279940%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638162216412834944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UBkZThWr%2BbEhc%2FV3jgSSlvdSsGMQ41gceRGSyPs5uFM%3D&reserved=0>)

I don't recall seeing a suggestion of an INTEGER() alias for INT().

Programming languages are often full of shortened and occasionally
cryptic spellings for things. The reason is usually historical (such as
the case here), but there has been a general preference to keep things
short, especially if they get used a lot.

Steve


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


More information about the J3 mailing list