Re: question about linker

On 02/12/2024 15:24, David Brown wrote:

On 02/12/2024 13:24, Bart wrote:

I would consider any kind of automatic import system to be a bad idea.

It's not automatic; you have to list the modules. If you don't want data shared, then don't export it!
If you want selected imports between arbitrary module subsets, then my scheme has 'subprograms' (see below), or you choose a language with a more chaotic module scheme that can give that flexibility, but requires more maintenance.

I like structured and modular programming.  It is strange to me that someone would have the tools for that, and then choose not to use them. But some people seem to prefer piling everything together in one name space.

This point was about individual functions not files. For example this in Python:
   from math import sqrt
(which also has the effect of making 'sqrt' part of this module's namespace).

Indeed - that's why I say it /sounds/ terrible to me.  As I said above, I prefer a clear and modular organisation.  If I am writing module "foo" and a colleague is writing module "bar" as part of the same program, the last thing we want is automatic import of each other's modules, symbols, functions, etc. - especially not jumbled into the main namespace for the code!

If you don't then you're not really writing the same part of the program. I mentioned my programs comprise subprograms, which have stricter import rules and which are non-hierarchical/non-circular.
It sounds like, in my scheme, you'd be working on different subprograms: each team member has their own chummy collection of modules.
But it's possible you are also working on the same collection. Then you talk!
C for example has one giant namespace anyway that contains all shared entities. /Then/ you have a problem, especially when people avoid 'static'.
My scheme allows modules A and B to both export a function F. If A and B are part of the same subprogram collection, then this means needing to qualify the function name, as A.F() or B.F(), depending on where it's defined:
p.m:
   module a
   module b
   proc main =
       a.f()
       b.f()
    end
a.m:
   global proc F = println "FA" end
b.m:
   global proc F = println "FB" end
   c:\mx>mm -r p
   FA
   FB
If I try the same in C:
a.c:
   #include <stdio.h>
   void F(void){ puts("FA");}
b.c:
   #include <stdio.h>
   void F(void){ puts("FB");}
I get a 'multiple definition of F'. This is without even getting as far as writing `p.c`, where it is impossible two distinguish between those two F functions.
When generating shared libraries like DLLs however, I can only export the base-name 'F'. If A and B are both compiled to its own DLL, that can produce similar difficulties.
A typical one here is that the linking process will only match one of the 'F's (my compiler matches A.F, gcc matches B.F, but neither report any ambiguity).
(Actually my scripting language handles this properly, but only because it requires its FFI to match each imported symbol with a specific DLL. So both A.F and B.F can be accessible from two DLLs that each export an unadorned 'F'.)