Re: question about linker

On 05/12/2024 14:00, David Brown wrote:

On 04/12/2024 22:31, Bart wrote:

And while you are at it, buy a better screen.  You were apparently unable to read the bit where I said that /saving typing/ is a pathetic excuse.

I can't type. It's not a bad excuse at all. I have also suffered from joint problems. (In the 1980s I was sometimes typing while wearing woolen gloves to lessen the impact. I haven't needed to now; maybe I've slowed down, but I do take more care.)

You said my namespaces were jumbled. They generally work as people expect, other than some different rules on name resolution.

 No, they work as /you/ expect.  Not "people".

The concept is so simple that is not much about it for anyone to tweak.
A qualified name looks like this (this also applies to a single identifer):
   A.B.C
'A' is a top-level name. It is this that the name-resolution in a language needs to identify.
Presumably, in your C and C++ languages, all possible top-level names must be directly visible. Only in C++ with 'using namespace' does it allow a search for names not directly visible, by looking also in certain places.
This is where the rules diverge a little from what I do. Given 'CHUMMY' modules X, Y, Z (which I deliberately choose), then each effectively includes 'using namespace' for each of the other two modules.
I also have a different rule when there is clash between the contents of a 'using' namespace, and the set of directly visible names. As I say below, I consider the former to be in an outer scope.
The basics are more or less the same; some details differ. You can't say that C++ has the final word on it just because that's the committee choice it made, and every other approach must be wrong.
So my approach is a little more informal, and more convenient. I could have gone another way so that instead of writing this:
    pcl_start()
    pcl_end()
which is allowed instead of full qualifers which would be this:
   pcl.pcl_start()
   pcl.pcl_end()
I could use your strict approach. Then I'd use a different naming scheme, so that it looks like this:
   pcl.start()
   pcl.end()
This is not that different from the above! But I'd be uneasy about using non-prefixed names within that library. (For one thing, 'start' is a special function name; and 'end' is a keyword! There'd be other clashes.)
In short, you are just quibbling. I probably implemented 90% of what C++ has, you're trying to make out it's utterly different and unsuitable.
BTW, once 'A' has been resolved, then .B and .C generally are unambigious in my static language (and may need runtime checks in my dynamic one, if A is a variable rather then a module or type).
In C++ however, I suspect that what .B and .C mean may be subject to overloads, inheritance, and who knows what else.

  You designed the language for one person - you.  It would be extraordinary if it did not work the way /you/ expect!

Yep. And yet, it is not some obscure, exotic monstrosity. It's not that different from most others, and it's not that hard to understand.

  That way they are influenced by lots of opinions, experiences, desires, and use-cases way beyond what any one person could ever have.

A shame it didn't work for C!

So the way namespaces work in C++ is something that - by my rough finger-in-the-air estimates - dozens of people were involved in forming the plans, hundreds of people would have had a chance to comment and

Yeah. Design-by-committee. Just about every feature of C++ is a dog's dinner of overblown, over-complex features. C++ doesn't do 'simple'. (Look at the 'byte' type for example; it's not just a name for 'u8'!)

That suggests that the ratio of people who expect identifiers from namespaces to require namespace qualification unless you /explicitly/ request importing them into the current scope, compared to the people who expect namespaces to default to a jumble and overwhelm the current scope, is of the order of millions to one.

They're not imported into the current scope, but an outer scope. Anything with the same name in the current scope will shadow those imports.
C and C++ both have block scopes, yes? So the potential is there for nested scopes dozens of levels deep.

Yes - /sometimes/ file lookup uses some kind of path.  That happens for specific cases, using explicitly set path lists.  Who would be happy with an OS that when they tried to open a non-existent file "test.txt" from their current directory in an editor, the system searched the entire filesystem and all attached disks?  When you use the command "tcc", would you be happy with a random choice - or error message - because someone else put a different program called "tcc.exe" on a network drive somewhere?

That's exactly how Windows works. I think Linux works like that too: since tcc.exe is not a local file, and it doesn't use a path, it uses special rules to locate it. Somebody could mess about with those rules.
So, why don't you always have to type:
   /usr/bin/tcc.0.9.28/tcc             # or whatever
instead of just 'tcc'?

No, I don't agree with them.  Yes, it is your choice for your language.
 But you choose to talk about your language - so I can tell you why I think they are not good design choices.

My design is to allow default 'using namespace'; see above.
That's ... pretty much it.

Your compiler and tcc don't reach ankle-level to gcc, clang or even MSVC

That's good.
I once had to build a garden gate for my house. I decided to make my own, and ended up with a 6' wooden gate which was exactly what I needed.
If LLVM made gates, theirs would have been 9 miles high. A little unwieldy, and probably a hazard for air traffic.

It doesn't show anything useful is possible.  No one else wants to compile the limited subset of C that you want,

That's not true. Thiago Adams would find it useful for one. Obviously I do.
Anyone using C an intermediate language would do so. As would anyone writing C up to C99.

nor do they want a C compiler written in some weird private language.

Weird? There's a lot more weirdness in C!

But it is not an alternative for other people.  It is not some kind of proof that compilers - real compilers for real work - don't have to be large.

I suspect your prefered compilers wouldn't even run on a Cray-1 supercomputer, perhaps not even dozens of them.
Yet people /were/ running compilers for all sorts of languages on machines that weren't as powerful. Professional people writing professional software.
You're effectively calling all those toys.