Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Mon, 2 Dec 2024 18:32:29 +0100
Organization: A noiseless patient Spider
Lines: 416
Message-ID: <vikqvf$3fhce$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> <vihili$2f79m$1@dont-email.me>
 <vihu63$2ipg0$1@dont-email.me> <vii3kq$2kmc8$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 02 Dec 2024 18:32:31 +0100 (CET)
Injection-Info: dont-email.me; posting-host="eb12cb7493a6307f7e53eb722d1fc348";
	logging-data="3655054"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX197Kt3Rh/ku1MU0kql1/Ert"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:00GWcvOY7oazcouHnXLsg4Wu+4E=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <vii3kq$2kmc8$1@dont-email.me>

On 01.12.2024 17:42, Bart wrote:
> On 01/12/2024 15:08, Janis Papanagnou wrote:
>> On 01.12.2024 12:52, Bart wrote:
> 
>>> Yes, but they made writing, reading and maintaining source code
>>> impossible. [...]
>>
>> Really? - For me it's exactly the opposite; having the keywords stand
>> out lexically (or graphically) is what adds to legibility!
> 
> In my syntax, you can write keywords in capitals if you want. It's
> case-insensitive! People using my scripting language liked to capitalise
> them. But now colour-highlighing is widely used.

I'm used to case-insensitivity; that was common back in the mainframe
days (given that there often was just upper case available; lower case
was, if at all available, achievable only in complex ways). That's why
other stropping types were prevalent, like a dot as a prefix, which
was also used for symbols unavailable in the character sets. I recall
Pascal's  a[x]  was written as  a.(x.)  (or something like that).

> 
> 
>> (I admit that hitting the Shift or the Caps-Lock key may be considered
>> cumbersome by [some/most] people. - I "pay the price" for legibility.)
> 
> There's a lot of Shift and Caps-Lock with writing C or C-style syntax.

(I think we should agree on that it's (at best) a personal preference.)

If we have a closer look and (instead of a single character) inspect a
more complete code fragment you may see that legibility, usability, and
cumbersomeness is existing to a much larger degree on other places, if
we compare code with different language design. To take a commonly seen
construct in "C"

  if (cond) {
    stmt1;
    stmt2;
  }
  else {
    stmt3;
    stmt4;
  }

with [spurious; compared to other languages] parentheses and braces.

  IF cond
  THEN
    stmt1;
    stmt2
  ELSE
    stmt3;
    stmt4
  FI

(of course you format that, e.g. the 'THEN', as you prefer), or just

  ( cond | stmt1 ; stmt2 | stmt3 ; stmt4 )

or would you really think final semicolons (which are not allowed like
that in Algol 68) make that better

  ( cond | stmt1; stmt2; | stmt3; stmt4; )

If I'd follow your complaints I'd get heated up by all these spurious
and annoying parentheses and braces in "C".

More so if you consider "cultural" ("locale") differences. Keyboards
in my country, for example, have no easy (ergonomic) access to the
characters  { [ ] }  which are accessible only by the 'AltGr' key and
above the number keys  7 8 9 0 . It's certainly easier to type the
common ( and ) keys for a formalized representation or use the legible
form with keywords IF THEN ELSE FI, which are both easily typed on any
keyboard. (I'm aware that my statement is ignoring Chineese keyboards,
for example.)

> [...]
> 
> The point is, these are exceptions; Algol68 requires every reserved
> word, which includes types names, to be stropped. It gives a very
> peculiar look to source code, which you see very rarely in other languages.

(Not "every" reserved word if you use other representations; like (||)
instead of IF/THEN/ELSE/FI, but okay.)

Well, concerning "peculiarities" I'm certainly not annoyed or anything
with what you seem to dislike [in Algol 68].

I certainly agree that the historic disadvantages with the restricted
character sets that lead to the prefix-point sort of stropping didn't
look nice (we had to accept that at those long past days). Though in
context of reserved names I never considered it an issue, it's more an
issue, IMO, (if you see the Pascal example above) in combination with
other characters.

And I certainly also have no problem with all-caps stropping, that
[for me] even adds to legibility (as I already explained).

> 
>> that with me. - I understood that you find it a good idea to implement
>> an own [irrelevant] language
> 
> You keep saying that. It's a real language and has been tried and tested
> over decades. Maybe it would be better if I'd just made up hypothetical
> features and posted about ideas?

I know your [irrelevant] language is an existing language - I don't
know where it's used, and I also don't care (and many/most/all here
also don't seem to care much).

You can of course (and certainly should) post your ideas with some
syntax that expresses your ideas.

Only the fact that you constantly mention "your language(s)" in the
discussions spreads the impression that you think we should compare
it - your language, not any feature - with "C" (or Algol 68), or with
any specific "C" compiler. I also have my doubts that "your language"
(and also your compiler) would withstand the market demands. That
are the reasons why I point out its irrelevance where you give the
impression that you think "your language" is the solution to some
problem. Often I observe that you have a very limited local focus
when valuating features, speed factor, and whatnot. - My personal
valuation is that it makes little sense to discuss any features in
the spotlight of your compiler(s) or language(s).

> 
>> (You may be a
>> candidate for using an IDE that alleviates you from such mundane
>> tasks.)
> 
> I use a syntax that alleviates me from that!
> 
> Many languages allow trailing commas in multi-line lists. The reason is
> EXACTLY to simplify maintenance. But you're suggesting it is only me who
> has such a problem with this stuff. Obviously others do as well.

No, I'm saying that you are discussing minor things, blow them up
unnecessarily, see problems in a detail and miss the whole picture
with the real issues and challenges.

And I don't want to start or foster a "Delimiter vs. Terminator"
war. (I'd suppose this has been done in the past and opinions and
pros/cons can be looked up.)

> 
>> With your argumentation I'm curious what you think about having
>> to add a semicolon in "C" if you replace a  {...}  block.
> 
> That's just more fun and games. I don't get the rules there either.
> Sometimes "};" is needed; sometimes it's not needed but is harmless;
> sometimes it can cause an error.

Actually you seem to know "C" less than many people here. - I know
where the commas and the braces have to go.

My point was another with these examples. (But I'm tired to explain
that in detail; thought it would be obvious.)

> 
>> Or, in the first place, what you think about semicolons in "C"s
>> 'if-else' construct (with parenthesis-blocks or single statements).
>> And what's actually the "statement" in  'if(b)s;'  and  'else s;'
>> and what you think about  'if(b){}else{}'  being a statement (or
>> not, since it's lacking a semicolon).
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========