Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Fortran was NOT higher level than C.  Was: Computer architects
 leaving Intel...
Date: Thu, 5 Sep 2024 11:36:22 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 236
Message-ID: <vbc53m$ahv7$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at>
 <vavpnh$13tj0$2@dont-email.me> <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
 <jwv8qw8o7zg.fsf-monnier+comp.arch@gnu.org> <vb7q5q$3f6cg$1@dont-email.me>
 <20240904113123.00002098@yahoo.com> <vba46k$3te58$1@dont-email.me>
 <20240905130424.00001218@yahoo.com>
Injection-Date: Thu, 05 Sep 2024 13:36:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="49b1fef9f6d2c4ff10ee0b8b71cf8125";
	logging-data="346087"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180SW3J7cRQ9oImv4jn0KoOy7cXFc0qcrs="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:Y7swuGmabdUHdI1JZYUhqRfACKY=
Bytes: 9964

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?

> 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.

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
========== REMAINDER OF ARTICLE TRUNCATED ==========