Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Sun, 1 Dec 2024 11:52:17 +0000
Organization: A noiseless patient Spider
Lines: 123
Message-ID: <vihili$2f79m$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <vi6sb1$148h7$1@paganini.bofh.team>
 <vi6uaj$3ve13$2@dont-email.me> <87plmfu2ub.fsf@nosuchdomain.example.com>
 <vi9jk4$gse4$1@dont-email.me> <vi9kng$gn4c$1@dont-email.me>
 <87frnbt9jn.fsf@nosuchdomain.example.com> <viaqh0$nm7q$1@dont-email.me>
 <877c8nt255.fsf@nosuchdomain.example.com> <viasv4$nm7q$2@dont-email.me>
 <vibr1l$vvjf$1@dont-email.me> <vic73f$1205f$1@dont-email.me>
 <20241129142810.00007920@yahoo.com> <vicfra$13nl4$1@dont-email.me>
 <20241129161517.000010b8@yahoo.com> <vicque$15ium$2@dont-email.me>
 <vid110$16hte$1@dont-email.me> <87mshhsrr0.fsf@nosuchdomain.example.com>
 <vidd2a$18k9j$1@dont-email.me> <8734j9sj0f.fsf@nosuchdomain.example.com>
 <vidnuj$1aned$1@dont-email.me> <87ttbpqzm1.fsf@nosuchdomain.example.com>
 <vie0j5$1g968$1@dont-email.me> <vieun5$1mcnr$3@dont-email.me>
 <vihamj$2cflq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 01 Dec 2024 12:52:19 +0100 (CET)
Injection-Info: dont-email.me; posting-host="260abbc7cb612e705398f4619d1c380f";
	logging-data="2596150"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188F7dkt4pSPDp4+LZc0/1Q"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:J7v0Zzw/j5sWXuJAcDqjimW9RxA=
Content-Language: en-GB
In-Reply-To: <vihamj$2cflq$1@dont-email.me>

On 01/12/2024 09:36, Janis Papanagnou wrote:
> On 30.11.2024 12:59, Bart wrote:

[About Algol68]

>> But I also considered it too high level and hard to understand.
> 
> This I find astonishing, given that it is (IMO; and different from C)
> a so cleanly defined language.

Algol68 was famous for its impenetrable specification. Its Revised 
Report was the programming language equivalent of James Joyce's 'Ulysses'.

I needed a clean simple syntax and 100% obvious and explicit semantics.

>> Even the
>> syntax had features I didn't like, like keyword stropping
> 
> Stropping was a way to solve the limited characters available in the
> system character sets. Practically, as an implementer, you could use
> any mechanism you like. (On the mainframe I had used symbols preceded
> by a dot, the Genie compiler uses uppercase, for example. None is a
> problem for the implementer.)

Yes, but they made writing, reading and maintaining source code 
impossible. You'd spend most of your time switching case, or babysitting 
semicolons (see below).

I can live without embedded spaces within identifiers - most languages 
do. That was the primary reason for the stropping.

If I really need to use a reserved word as an identifier now (which only 
happens if porting from another language), I can use a backtick:

    int `Int, `INT, `Int

This also enables case-sensitivity (my syntax was case-insensitive). I 
don't think case-stropping for example can manage that.

>> and fiddly rules about semicolon placement.
> 
> Huh? - The semicolon placement as delimiters is quite clear and (as so
> many things in Algol 68) also clearly defined (IMO). - So what do you
> have in mind here?

It just makes life harder. It special-cases the last statement of any 
block, which must be semicolon free, as it's strictly a separator. So:

* Adding a new statement to the end of a block, you must apply ; to the
   current last statement

* Deleting the last line, you must delete the ; on the previous.

* Move any of the lines about, and you may again need to update the 
semicolons if the last was included

* Temporarily comment out lines including the last, you must also 
temporarily remove ; from the line before the comments

* Copy the whole block elsewhere, you might need to add ;

* Temporarily comment out a whole block (or start off with an empty 
block that will be populated later) you need to use SKIP, another annoyance.

Usually you're not aware of this until the compiler tells you and you 
have to go back in and fix it.

Allow semicolons to be a /terminator/, and all that goes away. It's a no 
brainer. But then I don't like having to write semicolons at all, and 
generally I don't.

The whole thing with stropping and semicolons is just a colossal 
time-waster.
>>
>> As for better languages than C, there were very few at that level.
> 
> (But you know you can use Algol 68 on a system development level; we
> can read that it had been done at those day. - All that's "missing",
> and that's a good design decision, were pointers.)

The only actual implementation I've come across is A68G. That's an 
interpreter.

It runs my Fibonacci benchmark in 16 seconds. My main /dynamic/ language 
interpreter runs it in 1.3 seconds. My C interpreter, which I consider 
hopelessly slow, takes 6 seconds. My unoptimised C is 0.24 seconds.

Optimised C is 0.12 seconds, 130 times faster than A68G.

It's quite unsuited to systems programming, and not just because of its 
execution speed. However, I'd quite like to see A68G implemented in A68G!

Algol68 was a fascinating and refreshing language back then. It looked 
great when typeset in a book. But its practicalities were annoying, and 
now it is quite dated.


>> There would have been problems just getting it into the machine (since
>> on CP/M, every machine used its own disk format). And by the accounts I
>> read later on in old Byte magazine articles, C compilers were hopelessly
>> slow running on floppy disks. (Perhaps Turbo C excepted.)
> 
> (I don't get what argument you are trying to make. - That you wanted
> some terse language, maybe, as you already said above?)

That there were practical problems in physically getting the program 
into the machine. And when it did run, it would have taken minutes to 
build anything rather than seconds.

(See: https://archive.org/details/byte-magazine-1983-08/page/n111/mode/2up

A chart of compile-times is on page 122. The same issue compares 8086 C 
compilers, and introduces the C language.)

A lot of my HLL programs were short and intended to test some hardware. 
My resident in-memory compiler translated them more or less instantly. A 
formal build using disk-based programs, source files, object files, and 
linkers would have been too time-consuming (little has changed!).

I was generally regarded as a whizz-kid; that would have been difficult 
to keep up if my boss saw me twiddling my thumbs everytime he looked in.