Re: question about linker

On 04/12/2024 09:02, David Brown wrote:

On 03/12/2024 19:42, Bart wrote:

It really /does/ matter - regardless of what the language allows or does not allow.

>
Why?

 code the reading is important order people to.
 Or, if you prefer,
 Order is important to people reading the code.

 The compiler spends milliseconds reading the code.  Programmers spend hours, days, or more reading the code.  It's not particularly important if the language requires a particular order or not, except in how it helps or hinders the programmer in their order of the code.

You've lost me.
A language source file isn't a story that needs to be consumed sequentially. It will be a collection of functions that will have some arbitrary call-pattern at runtime, perhaps different each time.
So the static ordering is irrelevant. If you're looking at F, which calls G, and you want to look at G, then G is not always going to be immediately before F! It might be at any point before, so it might equally be at any point after. Or it could be located at anywhere in the 100s of modules that comprise the project.
In any case, you'd probably just click on G and it will take you there.
To put in another way, I've never noticed any particular pattern in function ordering of any open source project.
This sounds like something peculiar to you.

  And it is certainly the case that different programmers will prefer different ways to order and arrange their code - but that does not stop it being important.  When you write code, write it for human readers - other

And here I've lost track of what this particular complaint about me is about. But it looks like it would apply to the majority of the world's programmers.
Perhaps functions should be in alphabetic order?

I've already made it clear what I think is wrong about your solution - the jumbling of namespaces.  (And /please/ don't harp on about C's system again - the fact that C does not have a good way of handling namespaces does not suddenly make /your/ version good.)
 

All it does is allow you to write F() instead of A.F(). You can do the same thing in C++ (there it saves you writing A::), by doing this (AIUI):
>
   using A;

 (You mean "using namespace A;".  It's no problem that you don't know the right syntax for C++, but I'm correcting it in case you want to try anything on godbolt.org.)
 Yes, C++ /allows/ you to do that - if you explicitly choose to do so for a particular namespace.  Thus if you are going to use identifiers from a namespace often, and you are confident it will not lead to conflicts, then you can do so.  C++ "using namespace A;" is commonly used in a few circumstances:

It's used to avoid cluttering code with ugly xxx:: qualifiers, and save some typing at the same time. That's pretty much it.
To that end, C++ and my language achieve the same thing. I just decided to make 'using namespace xxx' the default, and haven't got around to making it optional. (In an early version, I did need such a directive.)
(However it most likely differs from C++ in what it calls 'namespaces'.
My remarks have been about the namespace that is created by a module.
I understand that C++ namespaces can be created in other ways, like classes. I sort of have that too, but rarely use the feature:
  record foo =
      proc F = println "FOO/F" end
  end
  record bar =
      proc F = println "BAR/F" end
  end
  proc F = println "MAIN/F" end
  proc main =
      foo.F()
      bar.F()
      F()
  end
Here, I don't need to create instances of foo and bar; they serve to encapsulate any kinds of named entities.)

Having every module in a program automatically pull in every exported identifier from every other module in the program is not structured or modular programming - it is anarchy.

In the 'subprogram'. The structure is there.
 > in every exported identifier
Yes, every EXPORTED identifier. An exporting module doesn't know which modules are going to access that identifier, and it doesn't have any control over that (I don't know of any scheme allows that; maybe you do?)
So it knows it could be used from anywhere that imports this module.
I decided to create a concept of a 'chummy' set of modules (the 'subprogram') which freely see others exports, while not seeing the local entities which are kept private.
Much like people in a rooming house call each other by their first names.

You get an error if you try to use "F", as it is ambiguous.

Same here.

  (Defining a new local function F is also an error even if F is never called.)

That I don't do, as it is the typical and expected behaviour when you have shadowing of names in an outer scope; generally it is not reported.
However, things can always be tweaked. I just find the model works fine for me.

This crashes. This program is impossible to write in my language when both modules are part of the program.

 I'm sorry, I thought you meant if a sane C programmer wrote good code but accidentally had conflicting types.  C is not as tolerant of idiots as some languages.

So it's a lot more fool-proof.

If you are a fool, you should probably avoid programming entirely.

Fuck you. Obviously you're going to shoot down whatever I say, trash whatever I have achieved, because .... I've really no idea.
Yesterday you tried to give the misleading impression that compiling a substantial 200Kloc project only took 1-3 seconds with gcc.
I gave some timings that showed gcc-O0 taking 50 times longer than tcc, and 150 times longer with -O2.
That is the real picture. Maybe your machine is faster than mine, but I doubt it is 100 times faster. (If you don't like my benchmark, then provide another in portable C.)
All this just so you can crap all over the benefits of small, faster, simpler tools.
I'm pretty sure tcc won't compile your projects, because your projects will be 100% dependent on the special features, extensions, and options of your prefered tools. So that is hardly surprising.
But that's not a reason to dismiss it for everyone else.

Languages and tools should try to be accident-proof, not fool-proof.

And yet my product IS fool-proof. So again, fuck you.