Re: Fortran was NOT higher level than C. Was: Computer architects leaving Intel...

On Thu, 5 Sep 2024 11:36:22 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Wed, 4 Sep 2024 17:08:36 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
 

Michael S <already5chosen@yahoo.com> schrieb: 

On Tue, 3 Sep 2024 20:05:14 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
  

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:   

My impression - based on hearsay for Rust as I have no
experience
- is that the key point of Rust is memory "safety".  I use
scare-quotes here, since it is simply about correct use of
dynamic memory and buffers.
>
It is entirely possible to have correct use of memory in C,
   

>
If you look at the evolution of programming languages,
"higher-level" doesn't mean "you can do more stuff".  On the
contrary, making a language "higher-level" means deciding
what it is we want to make harder or even impossible.     

 
Really?
 
I thought Fortran was higher level than C, and you can do a lot
more things in Fortran than in C.
 
Or rather, Fortran allows you to do things which are possible,
but very cumbersome, in C.  Both are Turing complete, after
all.   

>
I'd say that C in the form that stabilized around 1975-1976 is
significantly higher level language than contemporary Fortran
dialects or even the next Fortran dialect (F77).   

 
I did write Fortran, not FORTRAN :-)
 
I agree that C had many very useful things that pre-FORTRAN 90
did not have.  This is not surprising, since the authors of
C knew FORTRAN well.
 
[...]
 

Overall, the differences in favor of C looks rather huge.    

 
You are arguing from the point of view of more than 30 years ago.
 

On the other hand, I recollect only two higher level feature
present in old Fortran that were absent in pre-99 C - VLA and
Complex.    

 
You forget arrays as first-class citizens, 

>
In theory, this is an advantage. In practice - not so much.
Old Fortran lacked two key features that make 1st-class arrays
really useful - array length as an attribute and pass-by-value. 

 
You want to pass arrays by value?  In practice, that would mean
copy-in and copy-out.  Is this something that you do often?
>

In languages that I use daily it's not something you can decide freely.

I one group (C, to slightly less extent C++) passing arrays by value is
cumbersome  so I use it less than I would probably do if it was
more convenient.

In other group (Matlab/Octave) pass-by-value is the only available
option, so I use it all the time, but it does not mean much.

So, one can enjoy his 1st class citizenship only with borders
of procedure. 

 
Nope - you can declare a dummy array of DIMENSION (n,m,...), and
then not to have to worry about implementing the index arithmetic
yourself.  That was a big deal, in which C didn't follow Fortran.
 
But numerical code was only an afterthought in C, as you can
also see by its brain-damaged handling of errno for mathematical
functions and the fact that everything is promoted to double -
were sinf and friends even introduced before C99 (if you want to
be historical)?
 

 

and a reasonable way
to pass multi-dimensional arrays.  

>
Considering total absence of inter-module check of matching
dimensions, it's probably caused more troubles than it solved. 

 
Definitely not.  Yes, you had to keep counting dimensions, which
was a drag, but multi-dimensional arrays in C... whenever I needed
those, I used Fortran instead, also in the pre-F90 days.
 

 

Sure, you could roll them
on your own with pointer arithmetic, but...
 

>
OTOH, while C does not have formal concept of array slices, they are
very easily and conveniently emulated in practice. Surely, not
quite as nicely syntactically as in Modern Fortran, but equal to it
on practical ground. 

 
Please show an example how you would pass an 2*2 submatrix of a
3*3 matrix in C.
>

I said 'arrays'. I never said that it is easy for matrices :(
But it definitely works for matrices as well. C binding of LAPACK is a
good example of the typical API. The trick is to not forget to keep
lead dimension in separate parameter from number of columns (assuming C
conventions for order of elements in matrix).
I do use this trick in my signal processing practice.
But agree that for case of matrices C is only very slightly more
convenient than old FORTRAN.

In Fortran, this is, on the caller's side,
 
   real, dimension(3,3) :: a
 
   call foo(a(1:2,1:2))
 
or also
 
   call foo(a(1:3,1:3))
 
and on the callee's side
 
   subroutine foo(a)
   real, dimension(:,:) :: a
 

According to my understanding, emulation of slices in Old
FORTRAN is more cumbersome. 

 
In the original post, I was talking about Fortran (=modern Fortran,
F95ff), not F77 or earlier.  So this is a bit of a red herring.
 

The first feature can be emulated in almost satisfactory manner
by dynamic allocation. Also, I am not sure that VLA were already
part of standard Fortran language in 1976.   

 
It didn't.
 

The second feature is very specialized and rather minor.   

 
Let's take a look at Fortran 95 vs. C99 (similar timeframe), and
thrown in the allocatable TR as well, which everybody implemented.
 
Fortran 95 already had (just going through
https://en.wikipedia.org/wiki/Fortran_95_language_features
and looking at the features that C does not have)
 
- A sensible numeric model, where you can ask for a certain
  precision and range 

>
May be, it's good in theoretical sense, also I am not sure even
about it. 

 
That's as may be.
 

I most certainly don't like it as numerics professional (which I am
formally not, but a lot closer to being such than an average
programmer or an average physicists/chemist/biologist).
I very much prefer IEEE-754 approach of fixed list of types with
very strictly specified properties. 

 
If you want that, you can also have it (in more modern versions of
Fortran than Fortran 95).  But don't forget that, in this timeframe,
there were still dinosaurs^W Cray and IBM-compatible mainframes
roaming the computer centers, so it was eminently reasonable.  Fortran
then caught up with IEEE in 2003, and has very good support there.
 

- Usable multi-dimensional arrays
- Modules where you can specify accessibility
- Intent for dummy arguments
- Generics and overloaded operators 

>
Handy, but dangerous. 

 
Quite handy for putting in an operator like .cross. for
the cross product of vectors, for example.
 

 

- Assumed-shape arrays, where you don't need to pass array
  bounds explicitly
- ALLOCATE and ALLOCATABLE variables, where the compiler
  cleans up after variables go out of scope 

>
How does it differ from automatic variables that C together with
nearly all other Algol derivatives, had from the very beginning? 

 
You can allocate and deallocate whenever, so you have the
flexibility of C's pointers with the deallocation handled
by the compiler.
 
For example
 
  type foo
    real, allocatable, dimension(:) :: x, y, z, f
  end type foo
 
...
 
   type(foo) :: p
 
...
 
   allocate (p%x(n), p%y(n), p%z(n), p%f(n))
 
All of this will be deallocated when p gets out of scope.
>

I still don't see how it's more capable than C99 except for minor
ability to group automatic VLAs in sort of struct.

 

- Elemental operations and functions (so you can write
  foo + bar where foo is an array and bar is either an
  array or scalar) 

>
Yes, it is handy for certain classes of matrix and array processing.
Still less powerful than similar features of Matlab and esp.
of Gnu/Octave, where you have both matrix operations like * and
cell-by-cell operations like .* 

 
Use MATMUL for the array operations, it's an intrinsic.
 

Unfortunately, the meaning of code that  intensively uses this
features not always obvious to reader.
C code that achieves the same effect with utility functions is looks
much less nice, but at least it does not suffer from above mentioned
problem.
 

- Array subobjects, you can specify a start, an end and
  a stride in any dimension
- Array intrinsics for shifting, packing, unpacking,
  sum, minmum value, ..., matrix multiplication and
  dot product
 
The main feature I find lacking is unsigned numbers, but at
least I'm doing something about that, a few decades later :-) 

>
I don't know much about typical users of Modern Fortran, but would
think that those coming from other languages, esp. from Python,
would appreciate built-in infinite-precision integers much more
than unsigned integers. 

 
That wasn't the proposal I made.
 

BTW, do your unsigned integers have defined behavior in case of
overflow? Is it defined as a modulo 2**size?  

 
Yes.
 

If the answers are yes, then may be you can find better name than
'unsigned'? 

 
It's the name that C uses, and what people are used to.  It is a
bit out of my hand now, because the proposal has been accepted
by J3, but what other suggestions would you have?

In Ada Language manual they are called Modular types, which is not bad.
Unfortunately, specific modular types defined in Ada's predefined
packages are named Unsigned_nn and Cardinal. Neither is a name I would
suggest.