Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process.

On Wed, May 31, 2023 at 06:43:52PM +0000, Cecil Ward via Digitalmars-d-learn wrote:
> Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process.

Unlike C's #include, `import` does NOT paste the contents of the imported file into the context of `import`, like #include would do. Instead, it causes the compiler to load and parse the imported file, placing the parsed symbols into a separate symbol table dedicated for that module (in D, a file == a module). These symbols are then pulled into the local symbol table so that they become available to code containing the import declaration.

(There's a variation, `static import`, that does the same thing except the last step of pulling symbols into the local symbol table. So the symbols will not "pollute" the current namespace, but are still accessible via their fully-qualified name (FQN), i.e., by the form `pkg.mod.mysymbol`, for a symbol `mysymbol` defined in the module `pkg.mod`, which in turn is a module under the package `pkg`.)

For more information:

	https://tour.dlang.org/tour/en/basics/imports-and-modules
	https://dlang.org/spec/module.html


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth

On Wednesday, 31 May 2023 at 18:56:02 UTC, H. S. Teoh wrote:
> On Wed, May 31, 2023 at 06:43:52PM +0000, Cecil Ward via Digitalmars-d-learn wrote:
>> Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process.
>
> Unlike C's #include, `import` does NOT paste the contents of the imported file into the context of `import`, like #include would do. Instead, it causes the compiler to load and parse the imported file, placing the parsed symbols into a separate symbol table dedicated for that module (in D, a file == a module). These symbols are then pulled into the local symbol table so that they become available to code containing the import declaration.
>
> (There's a variation, `static import`, that does the same thing except the last step of pulling symbols into the local symbol table. So the symbols will not "pollute" the current namespace, but are still accessible via their fully-qualified name (FQN), i.e., by the form `pkg.mod.mysymbol`, for a symbol `mysymbol` defined in the module `pkg.mod`, which in turn is a module under the package `pkg`.)
>
> For more information:
>
> 	https://tour.dlang.org/tour/en/basics/imports-and-modules
> 	https://dlang.org/spec/module.html
>
>
> T

Thank you so very much for the links and for your generous help. Some C compilers used to have a thing called ‘precompiled headers’, potential source of trouble and ai always felt uneasy about it rightly or wrongly.

It’s great that D has got rid of header file includes though, they were ridiculously painful. I used to use the automake feature that was built into the JPI C compiler at work which took care of all the .h dependencies so you no longer had to worry about it. And you only loaded the compiler from disk and started it up once as it stayed in memory handling all the C parts of a make.

On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward wrote:
> Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process.

I have another question if I may, what do we do about getting makefiles right given that we have imports ?

On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward wrote:
> Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process.

I do wonder why no-one have linked the [Modules and libraries](https://ddili.org/ders/d.en/modules.html) section in the [Programming in D](https://ddili.org/ders/d.en/index.html) book! The book is outdated in some things (and this isn't with logic, I have found one of these cases myself) but for most things, it will be ok!

On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward wrote:
> Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process.

I do wonder why no-one have linked the [Modules and libraries](https://ddili.org/ders/d.en/modules.html) section in the [Programming in D](https://ddili.org/ders/d.en/index.html) book! The book is outdated in some things (and this isn't with logic, I have found one of these cases myself) but for most things, it will be ok!

On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote:
> I have another question if I may, what do we do about getting makefiles right given that we have imports ?

Others can correct me if I'm wrong, but I don't think that it is a priority for D to be specially compatible with makefiles in any way beyond the whole separation of compilation and linking.

On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote:
>
> I have another question if I may, what do we do about getting makefiles right given that we have imports ?

What do you mean with that? Give some more info please!

On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote:
> I have another question if I may, what do we do about getting makefiles right given that we have imports ?

You can replace your whole makefile by calling the compiler with -I (not always, but if you don't do funny things in your makefile).
- This ability of the D compiler was just recently discovered (after -I was implemented for other reasons), but it relies on the fact that we have imports.