Re: question about linker

On 02/12/2024 21:06, David Brown wrote:

On 02/12/2024 19:27, Bart wrote:

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

 As I understood it, or perhaps failed to understand it (after all, it's not as if there are published specifications, references,

https://github.com/sal55/langs/blob/master/Modules24.md
(A summary, mainly for my benefit, about a year old.)

tutorials or examples for your language)

I gave an example in my post, of the lead module for my C compiler. Older examples are in that link.
In all (counting the 'pcl' backend library) it comprises 36 source files in two folders; plus about 40 C headers in two folders, which are embedded into the executable.
This information is enough for the compiler, and nothing else, to locate all the necessary files and to build an EXE file.

you would list your modules for a program in one place, and then other modules in the program automatically import them all.

The logic used in the name resolution pass of the compiler allows visibiliy without needing full name-qualifying.
That is incredibly convenient. It means clean source code with no xxx. or xxx:: littering everywhere. I don't even need different sets of 'import xxx' in each module.
I can rename any module, and I only need to change the one file. I can move an exported function from one module to another, without making any other changes (eg. change all xxx.F() to yyy.F()).
I just wonder what sort of dog's breakfast C++'s new module scheme is, or will be.

   from math import sqrt
>
(which also has the effect of making 'sqrt' part of this module's namespace).
>

 This is sometimes convenient for functions that you are going to use a lot.  At other times, you use "import math" and then refer to "math.sqrt".

You can achieve the same thing with 'sqrt = math.sqrt'. Meanwhile my module scheme gives you that for free. With 20 minutes spare I could add an option for to turn it off.

Perhaps you simply don't know how teams might work.

Perhaps not. So? Not everyone works in a team.
However one scripting language I created allowed anybody to create 'horizontal' addons for my application with my involvement. They didn't need to modify or rebuild my app (or even restart it). Multiple people could create scripts even for the same instance of a running application.