Re: question about linker

On 06/12/2024 15:41, David Brown wrote:

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.

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.

My language:
   println =a,=b                  # 13 characters, 0 shifted
(And that space is optional!) In C (assume the existence of stdio.h):
   printf("A=%lld B=%f\n",a,b);   # ~28 characters, 8 shifted
Enough said.

  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

If you used my language, you can type Y.foo if you want. Nothing stops you doing that.
And if you were using it, I can make the ability to omit 'Y.' optional.
However, you'd need to get used to a language and compiler that is 'whole-program', with a slightly different approach

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.

It is suitable for a vast number of programs. I'm sure it could be used for multi-developer projects too. After all, don't your projects also place all project-structure info into /one/ makefile? Which developer has editing rights on that file?
Who decides what the modules are going to be? If one developer decided they need a new module, what is the procedure to get that added to the makefile?

 

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

 "Informal" is a common theme for your language and your tools.

Small, simple, easy, fast, effortless, informal, minimal dependencies, self-contained implementations. Yes, those are aim. And?
I guess people still use manual screwdrivers instead of power tools? Your tools are magnitudes bigger in scope than a powered screwdriver.
For wiring a plug etc, a power tool is over the top.

  And "convenient" means convenient for you alone, not other people, and certainly not other people working together.

You're guessing.

  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.

The design IS better in 100 ways, at least compared to C. Other modern, higher level languages have 100 things I don't have, don't understand, or would find impossible to use.
However a language at the level of C still appears to be extremely popular. I guess people like something that is not so intimidating and that they can feel in command of.
To that end, my language is still relevant. In any case, /I am not pushing my language/ or advocating people to ditch C in favour of it. Such a task would need to be done by someone else. I'm just using as an example of better design, one that as been proven in actual use.
Actually, I get a kick out of using my private languages which fixes nearly everything I find annoying about C.
And when I do write C, I also get a kick out of using my private C compiler, NOT written in C.

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.

I guess you haven't seen many exotic/esoteric languages.
You once described my syntax as clean and easy to understand; what's changed?

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.

PATH is a collection of paths that are searched in turn. There it will stop at the first match.
That's similar to my list of modules that are searched in turn. There it will find all matches and report an ambiguity if more than one.
However, my list is private to my project, while PATH is common to every command prompt and to whatever directory is current. Some programs could even manipulate the contents of PATH.

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.

The programmer knows how the language works. They will have chosen the modules that are grouped together.
The alternative is to have 50 modules of a project, where each module contains its own subset of 0 to 49 imports. That's up to 950 possible imports to maintain across up to 50 files. It sounds a maintenance nightmare. A dependency graph would need a pretty big sheet of paper!
Would it even allow mutual imports? If not then that's another nightmare, which is likely to generate lots of extra dummy modules which only exist to get around the restriction.
I'm sorry, but I tried such a scheme, and decided it was awful.

No, I'm calling tcc and your compiler "toys".

If something really criticial and imminent depended on your compiling and running some C code, and the only compiler to hand was tcc, then you'd use it! Either that or write some assembly or key in machine code.
Then it's not a toy!
But I'm curious now: would you call any bit of software a toy if it was only written with one client in mind?
Or if it was a highly streamlined and dedicated version of a much larger, more general purpose program?
Do you call the specialist compilers for some of your devices toys because they only support one target (and apparently badly sometimes)?
What about assemblers: would you call a 100KB assembler a toy compared with 1MB or 2MB one? There's not much to assembling: if it does the job, then what would be toyish about it?
How about linkers: I could likely write one in 100KB, which turns a bunch of .o/.obj files into a binary. What that be a toy?
I'm really interested now. Those bigger products will have hundreds of options. So is it having lots of shiny buttons, and lots of things to learn, that would earn your respect, even though the task at hand is pretty trivial?