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

Tue Apr 4 16:13:52 UTC 2023

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> 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 11:18 AM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Steve Lionel <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 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)

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/034c4bf3/attachment-0001.htm>