On 5/15/2022 8:34 AM, Andrea Fontana wrote:
> I've imported some libraries directly into D. Not the headers, the whole library.

Shazam! Tell us more!

On 5/14/2022 6:00 PM, forkit wrote:
> It'll be a long, windy road ahead to, for anyone having to maintain projects that explicitly, actively, encourage you to combine different languages.

I understand as well as anyone that languages evolve and need maintenance. But I am also very aware that despite C's popularity, it evolves very very slowly. So this is a fairly low risk for us.

On Sunday, 15 May 2022 at 17:44:48 UTC, Walter Bright wrote:
> On 5/15/2022 6:13 AM, Adam D Ruppe wrote:
>> 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.

Of course not. The whole point is to keep this separate: the D code is just normal D code. The embedded C code is just a string - just like with a D mixin.

But the mixinC construct, instead of passing that string through the D parser, passes it through the C preprocessor and C parser.

So it would be similar to a compile time function:

Node mixinC(string c_code) {
    c_code = c_preprocess(c_code);
    return parse(c_code);
}


It must form a complete ast node - just like a D mixin. So you can't

mixinC("#define START {");
mixinC("START");
// other code here
}


That won't work, since you can't make an ast node out of {. Same as how `mixin("{")` fails to compile.

But a complete node inside the string can be done, parsed as C, then have its node injected into D.

Max Haughton has a proof of concept PR already.


(my full proposal also includes exposing the preprocessor state as an immutable D object, so you can introspect the macros and define an order of operation through the return value. But even the basic thing with implied global state might be a step forward)

On Sunday, 15 May 2022 at 20:34:25 UTC, Adam Ruppe wrote:

> Node mixinC(string c_code) {
>     c_code = c_preprocess(c_code);
>     return parse(c_code);
> }


My vote for mixin!C Vs mixin!D

Andrea

On Sunday, 15 May 2022 at 20:34:25 UTC, Adam Ruppe wrote:
> On Sunday, 15 May 2022 at 17:44:48 UTC, Walter Bright wrote:
>> On 5/15/2022 6:13 AM, Adam D Ruppe wrote:
>>> 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.
>
> Of course not. The whole point is to keep this separate: the D code is just normal D code. The embedded C code is just a string - just like with a D mixin.
>
> But the mixinC construct, instead of passing that string through the D parser, passes it through the C preprocessor and C parser.
>
> So it would be similar to a compile time function:
>
> Node mixinC(string c_code) {
>     c_code = c_preprocess(c_code);
>     return parse(c_code);
> }
>
>
> It must form a complete ast node - just like a D mixin. So you can't
>
> mixinC("#define START {");
> mixinC("START");
> // other code here
> }
>
>
> That won't work, since you can't make an ast node out of {. Same as how `mixin("{")` fails to compile.
>
> But a complete node inside the string can be done, parsed as C, then have its node injected into D.
>
> Max Haughton has a proof of concept PR already.
>
>
> (my full proposal also includes exposing the preprocessor state as an immutable D object, so you can introspect the macros and define an order of operation through the return value. But even the basic thing with implied global state might be a step forward)

So far it looks like mixinC is semantically functional, the only slight hiccup with the scheme is that currently you can't have a C struct initializer as the input to one so you may need to use a mixinC declaration when in C an "expression" on the RHS would have sufficed.

A large subset of macros will be simple enough to turn into D ASTs directly. If it can't be then the identifier could he recognized and an error message shown to the user. I say this directly because so far ImportC ignores things it does not understand which will have to stop at some point.

On Sunday, 15 May 2022 at 14:57:36 UTC, Ali Çehreli wrote:
>
> ...
> That sounds like "I told you so," which doesn't help. Surely, you don't mean others did anticipate but still put "Trivial" anyway?
>

No. Others did anticipate it. That's why the Trivial tag was removed ;-)

But the PR was submitted with a Trivial tag, suggesting the person submitting that PR did not anticipate the long, windy road ahead (which others did).

Anyway, the point has been made. Can we move on?

On 5/15/22 16:50, forkit wrote:

> Can we move on?

Yes! :)

Ali

Nice, thank you!

On 5/15/2022 2:28 PM, max haughton wrote:
> I say this directly because so far ImportC ignores things it does not understand which will have to stop at some point.

I'm not aware of any case where ImportC silently ignores things it does not understand.