Re: question about linker

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

[ snip examples of "Bart's language" ]

 (It makes no sense to compare Algol 68 with "your language"

I had to look back to see what examples I'd posted. It seems you're refering to my backtick examples.
I was just saying that there are ways to use reserved words as identifiers in the rare cases that are necessary. I think C# uses "@" for example. In my case I sometimes need case-sensitive ones too.
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.

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?

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

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.

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

(This is obviously an issue you have; not the language. You should
have better written "Usually I'm not aware of this ...". And that's
of course a fair point [for you].)

The last bit of Algol68 I wrote, approaximately half my time was dealing with ";" errors or "SKIP", or forgetting to use upper case for keywords. Fact.

Allow semicolons to be a /terminator/, and all that goes away. It's a no
brainer.

 History and also facts of contemporary languages disagree with you.
(Re: "no brainer": You need a brain to understand or know that, of
course. - So my suggestion to you is obvious; inform yourself.)

Lots of languages have also done away with semicolons, or arranged things so that they rarely need to be written.

For example I find it a "colossal time-waster" to write an own
language given the many different existing ones

Not at the time I started doing that. Certainly not in a form that was available to me.
So the language already exists, and I'm just evolving it.
I was going to give it up in 1992 and switch to C (I had in mind changing jobs). Then I had another look at C - and changed my mind!

- 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.
My syntax makes typing easier because it is case-insensitive, there is considerably less punctuation, it's not fussy about semicolons, it allows type-sharing more, it doesn't need separate declarations, or headers, or ....
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)
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?
So what bad language features do you think are time-wasters that I should instead look at?

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. So how fast would A68 code run under an interpreter running under A68G?

(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?
IMO A68 is unsuitable for such things, and A68G doubly so.

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.
I didn't consider it again until 1992 as I said, because I would have needed a new compiler for my language to work with Windows. I ended up writing that new compiler (and became self-employed).

And the problems you/we
buy with that are directly observable in the languages. Rather we
seem to have accepted all their deficiencies and just work through
(or around) them. Most do that with not complaints. What I find
astonishing is that you - here known to complain about a lot of "C"
details - are now praising things (and at the same time despise
sensible concepts in an exceptionally well designed language as
Algol 68).

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.
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). You can't mix signed/unsigned arithmetic easily, it needs BITS, which are awkward to initialise.
It is really dreadful. It makes writing in C attractive!
(Below that is my version in the Algol68-inspired syntax, but you can see it looks quite different - and shorter.)
BTW under A68, the 100,000-loop ran in 11 seconds.
With my compiler, the 100,000,000-loop run in 1.5 seconds (1 second if optimised). So apparently 10,000 times faster.
If I use 100,000 in my version, and get my compiler to interpreter it (very slowly), it takes only 0.1 seconds, still 100 times faster!
(I think those long types slow down the A68 version.)
----------------------------------------------
MODE LI = LONG INT,
LB = LONG BITS;
LB mask = 8r 1 777 777 777 777 777 777 777;
LI mod = ABS mask + 1, l2 = 2;
LI t23 = l2^23, t25 = l2^25, t39 = l2^39, t41 = l2^41, t63 = l2^63;
[0:20631] LI q;
INT flag:=0;
LI carry := 36243678541,
xcng := 12367890123456;
LB xs := BIN LONG 521288629546311;
INT indx := UPB q+1;
PROC cng = LI: BEGIN
     xcng *:= 6906969069 +:= 123 %*:= mod
END;
PROC xxs = LI: BEGIN
     ABS ( xs := xs XOR (xs SHL 13 AND mask);
     xs := xs XOR xs SHR 17;
     xs := xs XOR (xs SHL 43 AND mask) )
END;
PROC supr = LI: BEGIN
     LI s;
     IF indx <= UPB q THEN
     s:=q[indx];
     indx+:=1
     ELSE
     s:=refill
     FI;
     s
END;
PROC kiss = LI: BEGIN
     LI s,c,x;
     s:=supr;
     c:=cng;
     x:=xxs;
     (s+c+x) %* mod
END;
PROC refill = LI: BEGIN
     FOR i FROM 0 TO UPB q DO
     LI h = ABS ODD carry,
         z = ABS (q[i]*t41%2 + q[i]*t39%2 + carry%2) %* mod;
         carry := ABS (q[i]%t23 + q[i]%t25 + z%t63) %* mod;
         q[i] := ABS NOT BIN (z*2 + h) %* mod
     OD;
     indx:=1;
     flag+:=1;
     q[0]
END;
LI x;
FOR i FROM 0 TO UPB q DO q[i] := (cng + xxs) %* mod OD;
FOR n TO 100000
DO
x := kiss
OD;
print (x)
----------------------------------------------
[0..20631]word Q
word carry  = 36243678541
word xcng   = 12367890123456
word xs     = 521288629546311
word indx   = Q.len
function refill:int =
     word h,z, cy
     cy:=carry
     for i in Q.bounds do
         h := cy iand 1
         z := (Q[i]<<41)>>1 + (Q[i]<<39)>>1 + cy>>1
         cy :=  Q[i]>>23 + Q[i]>>25 + z>>63
         Q[i] := inot (z<<1+h)
     od
     indx:=1
     carry:=cy
     Q[Q.lwb]
end
macro kiss = supr() + cng + xxs
function supr:int s=
     if indx <= Q.upb then
         Q[indx++]
     else
         refill()
     fi
end
macro xxs=(xs :=xs ixor xs<<13; xs :=xs ixor xs>>17; xs :=xs ixor xs<<43)
macro cng = xcng:=(6906969069) * xcng + (123)
proc main=
     word x
     for i in Q.bounds do
         Q[i] := cng + xxs
     od
     to 100'000'000 do
         x:=kiss
     od
     println "x =",x
end