Re: question about linker

On 05.12.2024 12:54, Bart wrote:

On 05/12/2024 10:59, Janis Papanagnou wrote:

On 05.12.2024 00:57, Bart wrote:

On 04/12/2024 22:58, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

>

OK, if it's so simple, explain it to me.

>
I'll pretend that was a sincere question.

>
Let's put it this way: if somebody asked me what the rule was, I
wouldn't be able to tell them.

>
If that is true I suggest to read one or two textbooks.

 
That answer suggests we're talking at cross-purposes.

(Always possible.)

 
So if the rules really aren't that simple, 100M users of the language
aren't going to find it any easier but wasting time looking this up in
textbooks.

I probably have a different view on that than you might have.

What I expect is that programmers, before starting programming,
learn the language they intend to program in. This is no waste
but a necessity. (Although in more recent times I observe also
different habits, with the then expected "quality" of output.)
Looking things (details?) up if in doubt is also no "waste" of
time.

If, OTOH, all you wanted to express is that a cleanly defined,
coherent language that makes look-ups rare, is better than a
quirky language with incoherences, many special cases, and a
lousy syntax, then of course I agree with that (as most folks
would certainly do).

 
That's not going to happen, and it they are casual users of their
compilers, they WILL write semicolons in the wrong place with no errors
reported. Until it bites.

Semicolons, really, are not the problem - AFAIR, in *none* of
the languages I was engaged with.

 
Fixing the language is always the best solution. Failing that, make
compilers report extraneous semicolons.

No, the best solution is a language that has been *designed*
[in advance] (in the first place).

[...]
 
Both pure separators and pure terminators have issues.

(Okay, I won't continue on that; I accept that you see or have
issues with semicolons.)

[...]
>
[ Awk syntax as example ]

 
What's the difference between a scripting language and any other?

For the purpose here the difference for me was the way how and
where I typically use "scripting" languages and languages that
are typically compiled respectively.

My general point is that I think a syntax should not depend on
layout (e.g. use of whitespace, column-specific symbols and
semantics, semantics of Tab-indented code, and, the choice of
line terminations as a lexical token). Syntax should (IMO) be
expressed in terms of visible tokens. (So that a reformatting
of source code will not, and IMO should not, change semantics,
or even produce errors.)

Scripting language seem often defined in a IMO suboptimal, more
lax way concerning semicolons. - But I admit, it's certainly
not a necessity that scripting languages must be more allowing
than non-scripting languages that are used in other contexts.

 
I've always wondered why people think a clean, clear, easy-to-understand
syntax is OK for a scripting language, but is no good at all for a
'REAL' programming language.

(I don't know where you get that from.)

The attributes you list are important for all types of programming
languages. (Would anyone disagree?)

(But consider Unix shell; its syntax is neither clean, nor clear,
or easy to understand, let alone its semantics. - I'm programming
on a daily basis with a Unix shell. I'm used to the syntax but it
is a pain and especially nothing comforting for newbies. - Also
in scripting languages, you cannot expect good syntax. I would be
mollified if newer languages, scripting or else, would at least
consider the experiences from inappropriate earlier attempts, but
no.)

[...]
 

I said that my generated code has to use ":;" after each label; it looks
weird.

>
It's funny that you put such an emphasis on labels. - Jumps to
labels have academically been long deprecated but, more importantly,
in my practical work I never had a need to use them (or even think
or considering to use them). (I suppose it's how one got socialized
to design and write programs.)

 
So you're one of those who never uses 'goto'. OK.

In fact, yes. But it's not a dogma, if you insinuated that. (I
might have used it once or twice, maybe in a some specific case,
but I wouldn't bet on that.) It's just that it turned out to be
unnecessary to write sophisticated code with 'goto'.

It's different in my Unix shell programs; here I'm sure that I
used 'break' (occasionally), 'continue' (rarely), 'break <N>'
(maybe once or twice).

In most cases 'goto' (and 'break' in shell) muddy the clearness
of control flow and (IMO) should be avoided. I happen to avoid
it just because it never appeared as necessity to even think
about using it

Janis

[...]