Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Fortran was NOT higher level than C.  Was: Computer architects
 leaving Intel...
Date: Thu, 5 Sep 2024 13:04:24 +0300
Organization: A noiseless patient Spider
Lines: 151
Message-ID: <20240905130424.00001218@yahoo.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 05 Sep 2024 12:03:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d1c3954e3e75afc5b6e38dec83749501";
	logging-data="3944887"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19G4mXhL9MpuyhAbMWbf86kf6d+xFtY0VQ="
Cancel-Lock: sha1:EbZSoEIqYBYDFx/oDgXrUQVNwHU=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 7469

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.
So, one can enjoy his 1st class citizenship only with borders
of procedure.

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

> 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. According to my understanding, emulation of slices in Old
FORTRAN is more cumbersome.

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

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

Handy, but dangerous.

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

> - 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 .*
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.
BTW, do your unsigned integers have defined behavior in case of
overflow? Is it defined as a modulo 2**size? 
If the answers are yes, then may be you can find better name than
'unsigned'?