From Newsgroup: comp.lang.fortran

On Sat, 27 Jan 2024 11:04:21 -0000 (UTC), Thomas Koenig wrote:

Fortran 90 was a modern programming language including all
the useful features of C (except unsigned numbers), but surpassing it in power by far.

It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.

On the plus side, seems it has a proper MODULE import facility
(reminiscent of Ada), as opposed to relying on the #include hack.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

On Sat, 27 Jan 2024 11:04:21 -0000 (UTC), Thomas Koenig wrote:

Fortran 90 was a modern programming language including all
the useful features of C (except unsigned numbers), but surpassing it in
power by far.

It even does recursive functions/subroutines. But you must explicitly declare them RECURSIVE, which C doesn’t.

It's the functionality that counts, not the syntax.

On the plus side, seems it has a proper MODULE import facility
(reminiscent of Ada), as opposed to relying on the #include hack.

One of the useful things (although it took SUBMODULEs to realize its
whole potential).
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.

It's the functionality that counts, not the syntax.

You shouldn’t need separate syntax to enable something that should be available as a matter of course.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.

It's the functionality that counts, not the syntax.

You shouldn’t need separate syntax to enable something that should be available as a matter of course.

What "should be available as a matter of course" is very much
an opinion, and there are two sides to that argument what should
be the default.

Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely
for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to
crash mysteriously with recursive subrotines, on modern systems.

So, should a compiler by default follow F2018 (which makes
procedures recursive by default) or not? Hmmm...
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

On Sun, 28 Jan 2024 08:54:48 -0000 (UTC), Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

You shouldn’t need separate syntax to enable something that should be
available as a matter of course.

What "should be available as a matter of course" is very much an
opinion ...

Every modern language has that capability.

Just one example: Stack sizes are severely limited even on modern
systems ...

Yes, but at least we can assume we have a stack.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

On 1/28/2024 2:54 AM, Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.

It's the functionality that counts, not the syntax.

You shouldn’t need separate syntax to enable something that should be
available as a matter of course.

What "should be available as a matter of course" is very much
an opinion, and there are two sides to that argument what should
be the default.

Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely
for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to
crash mysteriously with recursive subrotines, on modern systems.

So, should a compiler by default follow F2018 (which makes
procedures recursive by default) or not? Hmmm...

Definitely should NOT be the default.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

On Sun, 28 Jan 2024 08:54:48 +0000, Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.

It's the functionality that counts, not the syntax.

You shouldn’t need separate syntax to enable something that should be
available as a matter of course.

What "should be available as a matter of course" is very much an
opinion, and there are two sides to that argument what should be the
default.

Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to crash mysteriously with recursive subrotines, on modern systems.

So, should a compiler by default follow F2018 (which makes procedures recursive by default) or not? Hmmm...

I submitted a patch to implement the NON_RECURSIVE prefix and
made the change to make procedure recursive by default. It's
in bugzilla. Janne and I had a short discussion, and we are
both leary of what might happen with the stack; particular for
an OS that provides a small stack.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632
--
steve
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

On Sun, 28 Jan 2024 16:41:21 -0000 (UTC), Steven G. Kargl wrote:

I submitted a patch to implement the NON_RECURSIVE prefix and made the
change to make procedure recursive by default. It's in bugzilla. Janne
and I had a short discussion, and we are both leary of what might happen
with the stack; particular for an OS that provides a small stack.

Large objects tend to be variable in size anyway; how do you deal with
that? Do you stop and restart the program with a different global
allocation size?

In modern languages, we do most dynamic allocations, especially large
ones, in the heap.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

On Sun, 28 Jan 2024 16:41:21 -0000 (UTC), Steven G. Kargl wrote:

I submitted a patch to implement the NON_RECURSIVE prefix and made the
change to make procedure recursive by default. It's in bugzilla. Janne
and I had a short discussion, and we are both leary of what might happen
with the stack; particular for an OS that provides a small stack.

Large objects tend to be variable in size anyway; how do you deal with
that?

In a recent Fortran, a programmer can use

- Pointers The memory management is then done with ALLOCATE
and DEALLOCATE, much like C's malloc()/calloc() and free().
Known to be error-prone

- Allocatable variables. Allocating is done by the programmer,
deallocation can be done either manually or when the variable
goes out of scope. This can be somewhat tricky for compilers
to get right, but the burden is on the compiler writers,
where it belongs, and not on the programmers :-)

- An explicit shape with non-constant bounds, such as

subroutine foo(n)
integer :: n
real, dimension(n,n) :: a

Since Fortran 2008, this is also possible with BLOCK constructs.
This is similar to alloca() (a non-standard C construct) or
to VLAs in C.

The compiler is then responsible for handling the memory allocation
in a meaningful way - it can either allocate the memory on the
stack or on the heap.

Do you stop and restart the program with a different global
allocation size?

What people did in Fortran 77 and prior was usually to have a
global COMMON block which was then parcelled out piecewise.
Ugly, error-prone and no longer needed these days.

If you look at LAPACK intefaces, you still see lots of arguments
which are relatd to original and actual size of arrays - not pretty.
I wish they would use more modern features.

In modern languages, we do most dynamic allocations, especially large
ones, in the heap.

Assume you have a fixed-size buffer for some sort of blocked
algorithm. Where do you put it? If you make your subroutine
recursive, where it wasn't before, you suddenly end up using
a lot more stack, which then can crash a user's program.

And changing the default would cause that crash without source
code modification... which is bad.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

On Mon, 29 Jan 2024 06:54:14 -0000 (UTC), Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

In modern languages, we do most dynamic allocations, especially large
ones, in the heap.

Assume you have a fixed-size buffer for some sort of blocked algorithm. Where do you put it? If you make your subroutine recursive, where it
wasn't before, you suddenly end up using a lot more stack, which then
can crash a user's program.

And changing the default would cause that crash without source code modification... which is bad.

Precisely my point.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

Le 28/01/2024 à 16:56, Gary Scott a écrit :

On 1/28/2024 2:54 AM, Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

It even does recursive functions/subroutines. But you must explicitly >>>>> declare them RECURSIVE, which C doesn’t.

It's the functionality that counts, not the syntax.

You shouldn’t need separate syntax to enable something that should be
available as a matter of course.

What "should be available as a matter of course" is very much
an opinion, and there are two sides to that argument what should
be the default.

Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely
for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to
crash mysteriously with recursive subrotines, on modern systems.

So, should a compiler by default follow F2018 (which makes
procedures recursive by default) or not? Hmmm...

Definitely should NOT be the default.

The standard states this must be the default, so it has to be. Maybe some
time is needed to make the appropriate changes to the compilers, but eventually there should be no debate around this.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

Le 28/01/2024 à 09:54, Thomas Koenig a écrit :

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

On Sat, 27 Jan 2024 22:58:27 -0000 (UTC), Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

It even does recursive functions/subroutines. But you must explicitly
declare them RECURSIVE, which C doesn’t.

It's the functionality that counts, not the syntax.

You shouldn’t need separate syntax to enable something that should be
available as a matter of course.

What "should be available as a matter of course" is very much
an opinion, and there are two sides to that argument what should
be the default.

Just one example: Stack sizes are severely limited even on modern
systems, at least by default (and sometimes even more severely
for multithreaded applications). So, it is quite possible for an
application to work fine with non-recursive subroutines, but to
crash mysteriously with recursive subrotines, on modern systems.

I am a bit puzzled by such a debate.

First of all I don't get why the OS's define such small stack sizes by default, given the amounts of RAM that are available on current hardware.

Second, it's up to the compilers to follow appropriate allocation
strategies, and I must say that both gfortran and Intel Fortran have IMHO weird strategies:
- above a given size, gfortran reverts from stack allocation to static
memory (*)
- by default, Intel Fortran sticks to stack allocation for automatic variables/arrays and for temporary arrays, without bothering at all to
check the stack size

I would expect compilers to allocate small objects on the stack, and
larger objects on the heap.

(*) by the way, it's still unclear to me what happens in gfortran with
large automatic arrays when the size is not known at compile time?

Third, every programmer should be aware that large automatic objects are
not a good idea given the usually limited stack sizes.

And last, the main reason to get away from static variables in the
routines is multithreading, much before recursion.

So, should a compiler by default follow F2018 (which makes
procedures recursive by default) or not? Hmmm...

Of course it should. Adherence to the standard ensures portability.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

On Mon, 29 Jan 2024 06:54:14 -0000 (UTC), Thomas Koenig wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:

In modern languages, we do most dynamic allocations, especially large
ones, in the heap.

Assume you have a fixed-size buffer for some sort of blocked algorithm.
Where do you put it? If you make your subroutine recursive, where it
wasn't before, you suddenly end up using a lot more stack, which then
can crash a user's program.

And changing the default would cause that crash without source code
modification... which is bad.

Precisely my point.

Then I don't understand your point.
--- Synchronet 3.20a-Linux NewsLink 1.114