Re: question about linker

On 05/12/2024 16:29, Bart wrote:

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

Being unable to type, on its own, is not a good excuse - it's an essential skill for productive programmers.  But having joint problems /is/ a good excuse.  Three main ways of improving the situation would be getting a better keyboard (perhaps one of these with a split in the middle and more comfortable angles), using "stick keys" or other desktop tools to aid combination keys, and to use a good IDE and editor and a well-supported language that has structured scopes and identifiers, so that predictive input can significantly reduce the characters you have to type.  The goal of that last part is to reduce the number of characters you have to type, rather than the number of characters in the source code.

 

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.

"Simple" does not equate to "matching expectations".

 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.

There are a variety of additional situations where namespaces and scopes are searched in C++.  Some are fairly obvious - within a class method definition, other class members are directly visible.  Others such as argument-dependent lookup involve some very complicated rules - I'd be surprised if anyone in comp.lang.c++ can give an accurate summary of them all without looking up references.  (And for your own sanity, I'd advise against looking them up yourself!)  Without a doubt, these would be tough to implement in a compiler.  But the point of them is that, as far as possible, name lookup "just works" for the programmer as well as they might reasonably expect.  "Matching expectation" and being convenient to the programmer in most cases is certainly /not/ simple.

 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.
 

And that's the key flaw.  It is not what /I/ would expect, it's not what I think many other people would expect, and it is certainly not what I would want.  If I am writing module X and I want to use symbol "foo" from module Y, then I expect to say explicitly that I am using module Y (via an "import" or "include" statement), and I expect to say explicitly that I want "foo" from module Y (as "Y.foo", "Y::foo", "using Y", "using Y.foo", "from foo import Y", or whatever suits the language).
When I read a source file in any language, and I see the use of an identifier "foo", I want to know where that came from - I want to be able to find that out without doubt.  If it is written "Y.foo", then there is no doubt.  If I see "using Y.foo", there is no doubt - but I'd prefer that to be local to the function or block.  If I see "using Y", I know it might be from Y or it might be local to module X, but at least it is not in Z or some other unmentioned file.  If it is a symbol that is used a lot in the module, then maybe it worth a file-scope "using" statement of some kind - it will take more effort to figure out where it is from, but at least that knowledge will be re-used many times.
What you have done here is taken something that was close to being very useful, and turned it into something that is even worse than C - at least in C you have the #include lines, and because everyone knows it doesn't have namespaces you often get a clue from identifier names with prefixes.
You have snatched defeat from the jaws of victory in order to save a couple of lines at the start of each file - with the result that your language is only suitable for small single-developer programs.

So my approach is a little more informal, and more convenient.

"Informal" is a common theme for your language and your tools.  And "convenient" means convenient for you alone, not other people, and certainly not other people working together.  I suppose that is reasonable enough since you are the only one using your language and tools - why should you bother making something useful for people who will never use them?  But this is a root cause of why no one thinks your language or your tools would be of any use to them - and why you get so much backlash when you try to claim that they are better than other languages or tools.  Perhaps they are good for /you/, but not for anyone 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.

It /is/ obscure and exotic.  That's a given for a home-made one-person language - regardless of any similarities with existing languages. (Monstrosity or not is in the eye of the beholder.)

 

  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!

It did.

 

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'!)
 

"Simple" is not a goal for a language.  It is not helpful by itself.  A Turing machine is one of the simplest computing systems around - no one would want to write code with that!
C++ has a lot of complication.  Some of it is intentional, and a lot of it is a by-product of backwards compatibility - new versions can't re-do things with a better syntax or through out old parts.  (Remember, it's a real language - people can't just change the language and compiler when they want to write something a little differently in the source code.)
And a lot of C++'s complexity is about making it easier to use for the majority of the code.  Complicated template structures, rvalue references, and all the rest make it really difficult to make a good "vector" class.  But they mean it is possible to make a good vector class that other programmers can use - and it is okay if the job is difficult for the library developer or other C++ expert if the result is that ordinary code can be relatively simple and efficient.
I have a project where I have written a library for our card, while the customer writes the application, all in C++.  In the library I have a set of template classes for use with IO pins, including multiple inheritance, "curiously recurring template pattern", inline variables, and lots of other "advanced" stuff.  This all means that the guy writing the application code can write "led_red.on();" in a simple, clear manner and get the most efficient object code out of it.
Of course a language that is made to work for a vast number of people and a vast range of uses is going to be sub-optimal and overly complicated for any given person or any given type of project.  And it is entirely reasonable to say C++ is trying to do too much - it would be better to use different languages in different circumstances.
But it is still better than a language that is suitable for one person and one type of project - unless you happen to be that one person doing that one type of project.

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.

That's not better.

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.

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.

No, it is not.  You set PATH to the directories you want to use for binaries - the OS does not search the entire disk or random additional attached filesystems.

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'?

I explained that in the rest of my post.

 

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.

No, your design is to /force/ "using namespace" - whether the programmer wants it or not, and without the programmer even identifying the modules to import.  It's your choice - but it's a bad choice.

 

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.

Okay, "no one" is an exaggeration.  Let's say, less than 0.001% of C programmers would find your tools useful for actually writing code in C (rather than for messing around with tools to see what they 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.

People using Cray-1 computers would have used serious Cray-1 compilers in those days.  Since no one uses Cray-1 machines now, no modern compilers support them.  So I really don't get your point.  (I believe "Cray" is now part of HP, and pretty much all super-computers use gcc or clang/llvm for C these days.)

 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.
 

No, I'm calling tcc and your compiler "toys".  Long ago, people used simpler tools because simpler tools were all they had.  Now we have better tools.  People only write limited little non-optimising partial C compilers for fun, for learning, for experimentation, or for rare niche uses (such as to match their limited little cpu designs).  Those are all good reasons for doing so.  But if you want to develop a project in C with a view to producing executables that people will run, you don't use a toy when top-range tools are so easily available and do such a better job.