On 5/14/22 18:00, forkit wrote:
> On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:
>> ...
>>
>> It's been a longer and windy-er road than I'd anticipated, but isn't
>> that the way all software projects work?
>> ...
>
> Well...I'm not aware of any software projects where someone wakes up one
> morning, with a thought bubble, and then decides to submit a PR, marked
> as 'Trivial', that adds a C compiler insider an already existing
> compiler for a different language.

I am fortunate to be a part of a community where such inventions pop up from time to time.

>
> https://github.com/dlang/dmd/pull/12507/
>
> The long, windy road 'could' have been anticipated.

I did not read that threat but I can't see any comment by 'forkit' there. Could you not make yourself clear there to find a shortcut for the long, windy road? In any case I am missing your point. Are you wishing anticipation for the future? Or do you think we should rip this feature out completely? (I am asking those in the light of general negative sentiments.)

> I certainly anticipated it when I read that PR.

That sounds like "I told you so," which doesn't help. Surely, you don't mean others did anticipate but still put "Trivial" anyway?

> It'll be a long, windy road ahead to, for anyone having to maintain
> projects that explicitly, actively, encourage you to combine different
> languages.

Thanks for the heads up. I hope your attitude does not stop ideas for future invention.

More on topic, I am one of those who thinks ImportC is amazing and will be very useful. There is potential in it. The discovery of "modules for C" is unbelievable to me. It came only because one inventor thought an otherwise unrelated idea was worth pursuing.

Ali

On Sunday, 15 May 2022 at 13:13:09 UTC, Adam D Ruppe wrote:
> On Sunday, 15 May 2022 at 13:09:45 UTC, Nick Treleaven wrote:
>> Walter never claimed supporting all preprocessor macros would work.
>
> One of the interesting potentials of importC is that all of them *could* work:
>
> http://dpldocs.info/experimental-docs/mixinc.html
>
>> ImportC was very useful even not long after it was first merged.
>
> What did you use it for?

I've imported some libraries directly into D. Not the headers, the whole library.

On 5/15/22 08:44, Ola Fosheim Grøstad wrote:
> On Sunday, 15 May 2022 at 14:57:36 UTC, Ali Çehreli wrote:
>> More on topic, I am one of those who thinks ImportC is amazing and
>> will be very useful. There is potential in it.
>
> Yes, there is potential, but can we agree that encouraging people to use
> it (for other things than testing) is not a good idea until the feature
> is complete? You risk killing off the potential by locking it down to a
> premature design.

Agreed. This is a documentation bug: The following page should say "This feature is under construction.":

  https://dlang.org/spec/importc.html

At the moment it says "This document is under construction."

>> The discovery of "modules for C" is unbelievable to me. It came only
>> because one inventor thought an otherwise unrelated idea was worth
>> pursuing.
>
> What is it? I've seen it mentioned, but I don't understand what it is
> yet.

Walter explained the implementation of ImportC at this meetup:

  https://nwcpp.org/April-2022.html

He started from the point of view of the compiler writer, explaining symbol tables. Once a C file is parsed, it gets converted into a language-agnostic module. Once both D and C coexist as modules, they can interact as modules do. As a result, the following surprises emerge:

- C can import D
- C can call D struct constructors, destructors, .init, etc.
- C can import C (no more header files)
- Template instantiation from C
- Function overloads for C
- Introspection for C
- etc. (I can't think of right now what else may be hidden in there.)

The only requirement is to compile the C module with dmd.

I covered ImportC in a recent meetup but only Nicholas Wilson showed up and he and I had fun experiments with this feature:

  https://forum.dlang.org/thread/t0r1qn$2fnu$1@digitalmars.com

Our meeting was from the point of view of the user.

Ali

On 5/15/2022 6:16 AM, Vladimir Panteleev wrote:
> I'm looking forward to the future when we can stop worrying and deprecate the entirety of https://github.com/D-Programming-Deimos.

So am I. I'll be happy to bury it.

BTW, if anyone wants to start trying ImportC with Diemos projects, and reporting to bugzilla any issues encountered, we can move along even faster!

On 5/14/2022 7:12 PM, max haughton wrote:
> I will likely never compile a C dependency with ImportC directly, and I will definitely never import a D module into a C project

Consider that one thing ImportC enables is C code calling D code. This is important if your project is a mix of C and D code.

I did not anticipate or think of this when ImportC was conceived. It was a Eureka moment to discover it just kinda fell out of the implementation (adding 10 lines of code to close the circle!).

On 5/15/22 08:34, Andrea Fontana wrote:
> On Sunday, 15 May 2022 at 13:13:09 UTC, Adam D Ruppe wrote:

>> What did you use it for?
>
> I've imported some libraries directly into D. Not the headers, the whole
> library.


Same here.

I covered ImportC during a recent meetup. I literally did the following:


1) Copy/paste example code from libplot documentation into a D file.


2) Added the following line to my file:

  import plot;

Note: For that to work, I added the following line into my Makefile:

plot.i: plot.c Makefile
	gcc -I /usr/include -E $< > $@

Once plot.i is generated by the external preprocessor, D could just import it. I must disclaim that plot.c was needed to do the following:

// This is needed because __restrict is not supported
#define __restrict restrict

// This is needed to skip the definition of the __REDIRECT macro because certain
// compatibility declarations of 'fscanf' and friends could not be parsed. (?)
#undef __GNUC__

// This is needed because plot.h uses FILE but fails to include stdio.h
#include "stdio.h"

// This is what our program needs
#include "plot.h"


3) I changed two places in the example C code:

3.i) Added .dup.ptr to the following literal because D's literals are not the same as C's literals:

  "PAGESIZE".dup.ptr

3.ii) I changed the following manifest constant to D:

// #define MAXORDER = 12;
enum MAXORDER = 12;


Summary: I (almost) copy/pasted C code into D and the entire code worked without even thinking about any binding.

Then I further experimenting with importing C files and D files between each other. It just worked.

I understand it is even simpler today because I think the issue with __restrict is gone and D can preprocess.

Ali

On 5/15/2022 6:09 AM, Nick Treleaven wrote:
> Integrated C support with D has never been done before, and Walter never claimed supporting all preprocessor macros would work.

In fact I specifically said that the preprocessor macros would never fully work. Even though one could feed D source code through the C preprocessor, it will fail to preprocess, as D does not wholly consist of preprocessor tokens. (The ancient K+R preprocessor would, but standard C wedded the preprocessor semantics to C.)


> ImportC was very useful even not long after it was first merged. I'm surprised at some of the negativity from people here.

I'm not. I've done many projects that were universally derided as "who needs that" until they got their hands on it. :-)

I've also done many projects that everybody wanted, until I delivered it. (dscript)

It's kinda hard to tell these things in advance, especially if they involve a change in the way people are used to doing things.


> Features are not given up on unless they're deprecated. The problem is manpower and getting through the dip process. The waterfall software development method is well known. I think your narrative is unfair and breeds negativity about D. The problems can often be solved, and when they can't it's because it's a problem with no known good solution or a trade off. But none of that is relevant to ImportC, which has obvious merit yet requires more work but clearly will pay its way.

And now with:

  https://github.com/dlang/dmd/pull/14128

you can pass preprocessor commands to cpp when using ImportC. Getting better every day!

On 5/15/2022 6:13 AM, Adam D Ruppe wrote:
> On Sunday, 15 May 2022 at 13:09:45 UTC, Nick Treleaven wrote:
>> Walter never claimed supporting all preprocessor macros would work.
> 
> One of the interesting potentials of importC is that all of them *could* work:
> 
> http://dpldocs.info/experimental-docs/mixinc.html

It's an interesting idea, but I'm a little unsure how it works. Does it propose running D code through the C preprocessor? That does not work, as the C preprocessor will fail with D tokens.