The forked elephant in the room (page 16)

On 1/30/2024 7:36 AM, Mike Parker wrote: > There were discussions about the possibility of dmd compiling C code several years ago. My search attempts keep turning up way too many pages, but this is an old idea in the D community. The idea really goes back to C++. The C++ compiler could compile C code. Wanting to make this work for D was always on my mind.

On Tuesday, 30 January 2024 at 15:53:50 UTC, Mike Parker wrote:

On Tuesday, 30 January 2024 at 15:44:28 UTC, Mike Parker wrote:

On Tuesday, 30 January 2024 at 15:36:34 UTC, Mike Parker wrote:

There were discussions about the possibility of dmd compiling C code several years ago. My search attempts keep turning up way too many pages, but this is an old idea in the D community.

Okay, here's an early discussion. Not exactly the same, but in the ballpark:

https://www.digitalmars.com/d/archives/22625.html

And here's the earliest discussion of an ImportC-style thing that I can find (2006):

https://www.digitalmars.com/d/archives/digitalmars/D/35483.html

Why not enable dmd to "import" C header files directly?

One of the commenters listed this as a point against:

Writers of other D compilers will feel compelled to build in a C compiler so that they can compile such projects.

That's a lot earlier than what I found, but my recollection was that it had been floating around the whole time I've been using D. The idea isn't important for something like this - implementation is all that matters.

I attempted to hack a solution like ImportC at one time, with a script that would call dstep, a C compiler, and dmd. The compilation command was similar to what we have today. That went down in flames quickly because dstep couldn't fully translate headers.

On 1/31/2024 1:22 PM, Steven Schveighoffer wrote: > I also think the syntax can be clean without being ambiguous: > > ```d > // import(C) soundio; // sadly not available because import expressions > import!C soundio; > ``` The rationale for not having a special syntax for importing C files is the importer should not have to know what language the import comes from. That information should not "leak" into the importer's code. The point is seamless integration. Analogously, if one gets from a .di file import: ``` int foo(); ``` it should not matter what language foo() is implemented in. The caller should not need to know. Having to organize the file names and paths so this works is a very small price to pay for this abstraction. Besides, if you have these files in your folder: foo.c foo.d what is the maintainer looking at the files going to think? Which one is incorporated into the code? foo.c? foo.d? both? neither? It's a sloppy practice, not some vital thing to support. One can name files as one pleases, organize them into sensible folders, etc., all part of doing a good job as a programmer.

February 02, 2024

Re: The forked elephant in the room

Posted by Steven Schveighoffer
in reply to Walter Bright

Permalink

Steven Schveighoffer

Posted in reply to Walter Bright

Permalink

On Thursday, 1 February 2024 at 17:49:42 UTC, Walter Bright wrote:

On 1/31/2024 1:22 PM, Steven Schveighoffer wrote:

I also think the syntax can be clean without being ambiguous:

// import(C) soundio; // sadly not available because import expressions
import!C soundio;

The rationale for not having a special syntax for importing C files is the importer should not have to know what language the import comes from. That information should not "leak" into the importer's code. The point is seamless integration.

Analogously, if one gets from a .di file import:

int foo();

it should not matter what language foo() is implemented in. The caller should not need to know. Having to organize the file names and paths so this works is a very small price to pay for this abstraction.

This means you are changing the language based on the environment and on the whims of the compiler implementer. It's not a small price when it happens. In an ideal situation, where you control all files and environmental conditions, it could be fine. But we all live in the real world.

Besides, if you have these files in your folder:

foo.c

foo.d

what is the maintainer looking at the files going to think? Which one is incorporated into the code? foo.c? foo.d? both? neither? It's a sloppy practice, not some vital thing to support. One can name files as one pleases, organize them into sensible folders, etc., all part of doing a good job as a programmer.

In my case, it was:

raylib/rtextures.c

source/raylib/rtextures.d

And because D always looks in the current directory first, importing raylib.rtextures means the C file even though it wasn't intended to be part of the source code.

What was I intending? Not to have the C files participate at all, after all, they aren't in the source directory. My solution is to rename the C-containing folder to raylibc (which still could technically be imported, but I'm not sure how to fix that).

https://github.com/schveiguy/draylib/commit/9b04409fc3bda331d0a03583b2861552ffcaab04

In the general case, there are easily situations where C files might be in places that you need to specify an import path, where you only want one C file, but other C files that you don't want happen to conflict import-wise with D files in completely unrelated directories. It's not just the obviously wrong situation of putting a C and D file in the same directory.

D has this problem even with other D files. This is why I always recommend putting all your library files into a uniquely-named package. But with C files it's even worse, because C environments are not constructed with the import rules of D in mind.

-Steve

On Thursday, February 1, 2024 10:49:42 AM MST Walter Bright via Digitalmars-d wrote: > On 1/31/2024 1:22 PM, Steven Schveighoffer wrote: > > I also think the syntax can be clean without being ambiguous: > > > > ```d > > // import(C) soundio; // sadly not available because import expressions > > import!C soundio; > > ``` > > The rationale for not having a special syntax for importing C files is the importer should not have to know what language the import comes from. That information should not "leak" into the importer's code. The point is seamless integration. > > Analogously, if one gets from a .di file import: > > ``` > int foo(); > ``` > > it should not matter what language foo() is implemented in. The caller should not need to know. Having to organize the file names and paths so this works is a very small price to pay for this abstraction. > > Besides, if you have these files in your folder: > > foo.c > > foo.d > > what is the maintainer looking at the files going to think? Which one is incorporated into the code? foo.c? foo.d? both? neither? It's a sloppy practice, not some vital thing to support. One can name files as one pleases, organize them into sensible folders, etc., all part of doing a good job as a programmer. Well, I would point out that if import C had its own syntax, anyone who wanted it to be invisible as to whether importC was involved or not could just stick the importC import inside of another module and make the importC import public. Then code could import the D module without knowing or caring whether importC was involved or not - and when someone did want to make it clear that that's what's going on, they could just use the importC import directly. While I agree that you often don't want to have to care about which language defines something, prior to importC, you could at least rely on the fact that what you were importing was D code even if they were just declarations. And it's certainly my gut reaction that I very much want to know when I'm importing C code and not D code. Whether the module being imported is actually a D module or a C file changes what I have to look for when looking up the file to see what's in it, and hiding the fact that it's a C file just makes that harder. And in general, I want to know when stuff is extern(C), or extern(C++), or extern(D), or whatever because that does affect how it should be used. So, personally, I'm inclined to think that making importC imports distinct from normal D imports would reduce the number of problems involved rather than increase them, but it's also true that I haven't done anything with importC yet (the one time I tried, I couldn't figure out how to do it in the time that I had). So, I haven't had to actually deal with the pros or cons of how it currently works. - Jonathan M Davis

Forums