Re: question about linker

On 01.12.2024 12:52, Bart wrote:

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 see, you mostly find the specification document hard to understand,
and you have a point. (Not that I think that the C standard documents
texts that are occasionally posted here would be easy to understand.
Standards are certainly no textbooks. Myself, for example, I had the
arguable honor to implement an X.500 system for an European telephone
directory collaboration; the ITU-T X.500 series was vastly copious.)

Where I'd disagree is if you mean that Algol 68 as a language is, from
a programmer's perspective, hard to understand. Compared to "C" I think
it's a lot simpler (despite its richness of language features) due to
its clear formal design (and as opposed to "C" with all its design
quirks). And that's also true if compared with languages that have a
more streamlined design. (YMMV.)

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

Looks like we agree. (But you obviously came to a different conclusion
than me.)

[ Stropping ]

 
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! (Even if I
design and formulate an algorithm as a sketch on paper or white board
I underline the keywords. On a contemporary terminal you'd use syntax
highlighting [ that some folks, as I've learned, also don't like ].)

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

[...]
 
If I really need to use a reserved word as an identifier now [...]

(BTW, some language allows that by context sensitivity; in Unix shell,
for example, you can write    for for in in ; do : ; done    without
"stropping".)

[ snip examples of "Bart's language" ]

(It makes no sense to compare Algol 68 with "your language" and discuss
that with me. - I understood that you find it a good idea to implement
an own [irrelevant] language to serve your needs [and preferences].)

 

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.

You have problems to separate new statements from existing ones,
and remove that semicolon if you delete/relocate code. - Okay, I
see where you're coming from; I'm feeling with you. - But really,
we're typing tons of code and your problem is the semicolon in
cases where you restructure parts of your code? - (You may be a
candidate for using an IDE that alleviates you from such mundane
tasks.)

With your argumentation I'm curious what you think about having
to add a semicolon in "C" if you replace a  {...}  block.
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).

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

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

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

But then I don't like having to write semicolons at all, and
generally I don't.

(You're a Python fan/candidate? - It might serve your needs here.)

Frankly, after the era of line-oriented languages, there's a need
in syntactically organized imperative formally specified languages
to separate the statements from each other. (Some designers used
terminators instead for "easier parsing", as they said.) Not using
semicolons at all is commonly seen in shell or scripting languages
where (again) the line termination typically fills the gap. Where I
use Shell or Awk I also avoid spurious semicolons. But that is not
the case in the "regular" ("non-scripting") programming languages.

If I have terminators, good, if I have separators, good, if the
language allows 'Empty Statements', good, if I may use 'SKIP', good,
if I can omit it, good, if my language has line-terminated commands,
fine. - I'm sure that someone who will have a strong opinion of
what's good or not in that list is doomed to implement a language
supporting his own preferences (unless choosing any existing one
that supports is anyway).

 
The whole thing with stropping and semicolons is just a colossal
time-waster.

(I have completely different view on that but I accept your opinion.
For example I find it a "colossal time-waster" to write an own
language given the many different existing ones - 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.)

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

 
[ re-iterated speed argument in comparison with "own" languages
  while completely neglecting the other factors (including speed
  of development process) snipped ]
 
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.

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

 
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.

You are generalizing and (beyond stropping and semicolons) vague
about "its practicalities". (And the two specific design decisions
you obviously have issues with are not an Algol 68 specific thing.)

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

YMMV.

Janis

[...]