The new features of Fortran 202x

[Beliavsky]

At Fortran Discourse https://fortran-lang.discourse.group/t/fortran-202x-features/388/3 the new paper by John Reid, "The new features of Fortran 202x", https://wg5-fortran.org/N2151-N2200/N2194.pdf was mentioned.
No more features have been added to the lists of obsolete and deleted features.

Some sections are

Language elements
Intrinsic procedures and intrinsic modules
Interoperability with C
Input-output
Coarrays
Procedures
Array features
Enumerations

[Gary Scott]

hmmm...no bit strings :(

[Steve Lionel]

On 3/23/2022 11:45 AM, Gary Scott wrote:
> hmmm...no bit strings :(

See
https://stevelionel.com/drfortran/2020/08/11/doctor-fortran-in-were-all-bozos-on-this-bus/
for some words on that.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

[Dan Nagle]

Hi,

On Mar 23, 2022, Gary Scott wrote
(in article <t1ffb5$f4r$1...@dont-email.me>):

> hmmm...no bit strings :(
bit strings are usually taken as implying a new type.
New types are expensive for compilers, so to add a new type to the language
you must find an important use case difficult to support without a new type.

--
Cheers!

Dan Nagle

[Robin Vowels]

Bit strings have been available in PL/I since 1966. No big deal.

[Thomas Koenig]

Dan Nagle <danl...@mac.com> schrieb:

Bit strings can be implemented without too much trouble using the
existing intrinsic functions plus boz constants.

What I find difficult to get around sometimes is the lack of
an unsigned integer type, for exact interaction with C and for
reading or writing file formats which have unsigned lengths.
I usually resort to using C, then (the horror!)

[Thomas Koenig]

Just going through the document... a few thoughts.

# The limit of 255 continuation lines is removed and the limit on
# statement length is raised to a million characters.

# These relaxations are designed to support programs that are
# constructed mechanically. It not expected that they will be needed
# in programs written directly by people.

# These are hard limits. Processors are required to issue warnings
# if they are breached.

Love that one. A million also makes sure that this is clearly
recognizable as an artifical limit - had 1048575 been used,
somebody would have wondered about a 20-bit limitation somewhere.

Automatically allocating the length for get_command - great.
Saves me quite a few lines of code (inquiring about the length,
allocating the character, filling in the argument).

Splitting tokens - also quite useful. I'll probably get to
write it once, for libgfortran, instead of quite a few times
in my own programs.

selected_logical_kind: James will be pleased.

Plus there is some more - enums and coarray stuff.

Sounds like a few irksome things were fixed in that revision.
Looks good to me :-)

[Beliavsky]

Thanks to you and the other gfortran volunteers for your efforts. As features
are added I will publicize them on Twitter FortranTip.

[Robin Vowels]

.
There's no problem either with PL/I or Fortran in reading
and writing picture file formats that have unsigned lengths, etc.

[James Van Buskirk]

"Steve Lionel" wrote in message news:ja0ujj...@mid.individual.net...

> On 3/23/2022 11:45 AM, Gary Scott wrote:
> > hmmm...no bit strings :(

> See
> https://stevelionel.com/drfortran/2020/08/11/doctor-fortran-in-were-all-bozos-on-this-bus/
> for some words on that.

So
char([integer::Z'48',Z'65',Z'6C',Z'6C',Z'6F',Z'2C',Z'20',Z'77',Z'6F',Z'72',Z'6C',Z'64'])
but not
[character::Z'48',Z'65',Z'6C',Z'6C',Z'6F',Z'2C',Z'20',Z'77',Z'6F',Z'72',Z'6C',Z'64']
?
And still no
char(Z'21') !?

[James Van Buskirk]

"Thomas Koenig" wrote in message
news:t1fp0j$k3p$1...@newsreader4.netcologne.de...

> selected_logical_kind: James will be pleased.

James who? Since there are different internal representations of .TRUE.: x
/= 0,
BTEST(x,0), TEST >= 0, and the gfortran representation, there may be
different
kinds with the same size.

[Thomas Koenig]

James Van Buskirk <not_...@comcast.net> schrieb:

> "Thomas Koenig" wrote in message
> news:t1fp0j$k3p$1...@newsreader4.netcologne.de...
>
>> selected_logical_kind: James will be pleased.
>
> James who?

Van Buskirk :-) Are you?

>Since there are different internal representations of .TRUE.: x
> /= 0,
> BTEST(x,0), TEST >= 0, and the gfortran representation, there may be
> different
> kinds with the same size.

There are different internal representations in use, but certainly
not in the same compiler with the same options.

And C_BOOL pretty much settled the question about the internal
representation.

[Steve Lionel]

On 3/24/2022 2:51 AM, James Van Buskirk wrote:
> So
>
> char([integer::Z'48',Z'65',Z'6C',Z'6C',Z'6F',Z'2C',Z'20',Z'77',Z'6F',Z'72',Z'6C',Z'64'])
>
> but not
>
> [character::Z'48',Z'65',Z'6C',Z'6C',Z'6F',Z'2C',Z'20',Z'77',Z'6F',Z'72',Z'6C',Z'64']
>
> ?
> And still no
>   char(Z'21') !?

Correct. Note that the definition of the CHAR intrinsic is NOT "transfer
the bit pattern" but "a value in the range 0 ≤ I ≤ n−1, where n is the
number of characters in the collating sequence associated with the
specified kind type parameter" It's not much of a hardship to write
char(int(Z'21')) or use your first form of an array constructor.

I'd also wonder how an attempt to shoehorn BOZ constants into CHAR would
deal with character sets that have varying number of bytes (UNICODE, etc.)

You are welcome to make a proposal to enhance the use of BOZ constants
in character contexts - https://github.com/j3-fortran/fortran_proposals
is a good place for that.