Re: question about linker

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

 
That's something else that Algol68 fixed, and which other languages have
copied (Lua for one).

I'm not sure what (wrong) paragon you think Algol 68 had that it
would have fixed. To me it seems that they effectively designed
the language ("almost") from scratch. It was influential to many
languages (including "C" and Unix shell - just mentioning these
two since it's not obviously seen given their syntax - or Eiffel,
and many more).

(I can't tell about Lua, a language that I just don't know.)

 
[ snip personal problems with writing Algol 68 programs ]

[...]
 

- some even available
in source code to continue working on an existing code base. Colossal
is here a really perfect chosen adjective. - Your scale seems to have
got impaired; you spot marginal time "wastes" and miss the real ones,
qualitatively and quantitatively.)

 
I put a lot of weight on syntax; obviously you don't.

Where do you get that idea from? - Your mind is a puzzle to me.

Given that (in the course of the threads) I mentioned so many
syntactically different languages I'm practically experienced
in, and specifically discuss so many syntactical issues (good
ones and bad ones), I have no idea what your brain does when
it reads the posts.

 
My syntax

(See what I wrote above about "your {language,compiler,syntax}".)

makes typing easier because it is case-insensitive,

I don't think that case-insensitivity is a Good Thing. (I also don't
think it's a Bad Thing.)

But I want my software maintainable and readable. So my experience
is that I want some lexical "accentuation"; common answers to that
are for identifiers (for example) Camel-Case (that I used in C++),
underscores (that I use in Unix shell, Awk, etc.), or spaces (like
in Algol 68, but which is practically irrelevant for me).

For keywords I prefer to use uppercase (if the language is case
insensitive, like in Simula, or if the compiler requires it, like
in Algol 68).

there is considerably less punctuation,

A language property I very much appreciate.

(Sadly "C" and C++, that I commonly use, are bloated with it.)

it's not fussy about semicolons,

From the languages I know of in detail and I'm experienced in none
is "fussy" about semicolons. Rather it's a simple and well designed
syntactical token, whether used as separator or terminator. You've
just to put it where it's defined.

(Don't confuse "fussy" handling with "not matching your ideas or
preferences". - It's really, and obviously, you who has a problem;
here supposedly: understanding of serialization concepts.)

it allows type-sharing more,

(Don't know what you mean here.)

it doesn't need separate declarations,

Huh?

or headers, or ....

(You're obviously again trying to mis-match any language with your
personal software project.)

 
The end result is that less text needs to be typed, source looks cleaner
and it's less error prone. I don't need to write:
 
  for (int index = 0; index < N; ++index)

Sure. And there's a lot languages existing where you don't need to
write such ugly syntactical constructs (Simula, Algol 68, Pascal,
Eiffel, ...). That's what we have to buy when using languages that
inherited their syntax from "C".

 
for example. Or, to share a named entity, I don't need to write two
versions of it, one here and the other in a shared header. You don't
think that is a good thing?

For answers see above. (We can discuss any feature you like.)

 
So what bad language features do you think are time-wasters that I
should instead look at?

(Does this sentence make sense? - I don't understand it.)

What I can say on the keywords (language, features, time-wasters) you
used is...

There's thousands of languages existing, and many dozens widely used.
It's certainly a "colossal" (I like your word) time-waster to write an
own language instead of choosing a sufficiently fitting existing one.

Features are what they are; you need them or not.

(My suspicion is that at the time you started your project(s) you
haven't seen any options and wanted [to create] some solution. And
once you had your code base it was easier to continue your chosen
path than to reconsider the [later available] options. - There's
nothing to criticize with that. After all, it's a personal project.)

 

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!

>
I've heard and read, as I said, a differing thing about that.
Specifically I recall to have read about that special topic you
mention of writing an Algol 68 compiler in Algol 68; it has been
done.

 
I'm sure it has. My point about A68G is that it is interpreter, a fairly
slow one.

Have you checked? (I haven't, since I anyway only rarely use it.)

So how fast would A68 code run under an interpreter running
under A68G?

We had been discussing your point about Algol 68 being a system
programming language. It had been classified as such.

We had been discussing about your (just for the argument made up)
question whether there's an Algol 68 compiler written in Algol 68
(likely as an indication of the previous point). And I said that
this was indeed the case. (Despite it being not necessary to prove
the system programming language property.)

Then you project a current Algol implementation in a try to make
a principal argument. - You're obviously not interested in a fair
dispute about the languages or systems.

Concerning the Algol 68 Genie compiler - that you seem to mean
when you write "A68G"; there's an 'a68g' executable, but there's
no Algol 68G implementation, as opposed to Algol 68C, R, H, etc.)
- it's documented as "Algol 68 hybrid compiler-interpreter". (You
can read about the implementation concept in the "Genie" manual.)

 

(Your personal preferences and enthusiasm should not get in the way
of either checking the facts or formulate your opinions/thoughts as
what they are, here basically wrong assumptions based on ignorance.)

 
Really? I've written countless compilers and interpreters. Mainly I
devised systems programming languages. You think I don't know my field?

From your posts I've got quite a good impression of what you know
(and what you don't know, or just prefer to ignore).

(Your post that I'm replying to here confirms my impression.)

 
IMO A68 is unsuitable for such things, and A68G doubly so.

Yes, I have already acknowledged that every opinion (yous included)
is fine.

 

It makes me smile if you speak about "looking great when typeset",
given that the languages we use nowadays, specifically (e.g.) "C",
C++, don't even look good "when typeset".

 
Yeah. The first time I saw C code was in K&R1, in a book I bought in
1982 (for £12; a lot of money). It looked dreadful. The typeface used
made it look anaemic. That really put me off, more than the practical
problems.

Well, I'm of course biased by my own experiences and valuations.

Some others in my vicinity were euphoric about the language and
about the book. Concerning the language I did as I did with every
language I was confronted with; I tried to identify the good parts
and pondered about how to use the bad parts to my advantage; it's
not that "C" wouldn't have its merits. The book, OTOH, left me with
more questions than I initially had. (I seem to recall to have heard
that later editions were better in that respect.)

[...]
 

[...]

 
I admire languages that adapt and evolve. Fortran for example. C adapted
poorly and slowly. Algol68 apparently hasn't evolved at all. I guess it
couldn't do without changing it's RR, a big undertaking.

I haven't followed Fortran beyond F77; I wholeheartedly dislike it.
(I used Fortran just twice in my life; in a University project and
at the DLR to access a random-noise function from a Fortran library.)
I agree with what you say of "C" and Algol 68. (Although Marcel had
supported quite some noteworthy features in the "Genie" compiler!)
I don't understand what you are referring to with "RR". (For me it's
just an acronym for RoboRally, a nice board game.)

 
Which means it's stuck in the 1960s with some dated design choices.
 
BTW below is an actual example of Algol68 for A68G. It shows various
issues, other than syntax (but notice those jarring ";" after the END of
each function).

Well, we already addressed that; you need some separation token (or
else a termination token). (And we don't need to repeat ourselves.)

You can't mix signed/unsigned arithmetic easily, it
needs BITS, which are awkward to initialise.

I will snip that. In this detail I think it's inappropriate for this
newsgroup, and I certainly don't want to discuss that here. The posts
got already far too long (and for little gain, as I see it).

I will inspect your efforts, though; I'm always keen to learn. :-)
And thanks for providing the Algol 68 example; rarely seen nowadays.

 
It is really dreadful. It makes writing in C attractive!

As I wrote above, "C" has its merits. (And not only in comparison.)

(BTW, I find your Algol 68 sample not very well written, quite ugly,
to my taste. - As so often said; you can in any language write good
or bad code. - And style and readability preferences vary anyway.)

But the Algol 68 code - even your low-level code - "dreadful"!?
(I suggest to downgrade your comparisons a bit.)

Janis

[ Low-level code sample in Algol 68 vs. Bart's language snipped ]