Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Janis Papanagnou 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: References: <87plmfu2ub.fsf@nosuchdomain.example.com> <87frnbt9jn.fsf@nosuchdomain.example.com> <877c8nt255.fsf@nosuchdomain.example.com> <20241129142810.00007920@yahoo.com> <20241129161517.000010b8@yahoo.com> <87mshhsrr0.fsf@nosuchdomain.example.com> <8734j9sj0f.fsf@nosuchdomain.example.com> <87ttbpqzm1.fsf@nosuchdomain.example.com> 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: 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 ==========